ArticleElementRepository in AnkiBooks (refactor of OrderedElementRepositoryBase)
After writing the post yesterday, I was thinking about it some more, and wondering about the design. I also noticed some other small issues while writing the post:
I didn’t really like the naming inconsistency happening with the use of “OrdinalChild” and “OrderedElement” in the naming
Querying for all the sibling elements in the delete method was not necessary, it did save work by reusing a method though
Wondering if IOrdinalChild interface can be removed
I thought about a few different ways to change the design today. I think it may have been a mistake to couple the abstraction of this to the “OrderedElements” aspect of the article elements. It’s possible that other tables in the database could have ordered elements in the same way and an abstract repository to handle all cases of it would be good. However at this point for me, only article elements are doing this. I also considered that the handling of article elements ordinal positions will probably evolve to a more special case to allow moving article elements from one article to a different article.
After refactoring, the main class relevant to the post is the following ArticleElementRepository. A repository specific to each article element type will derive from it and add the read methods. The main reason for not including the read methods here is eager loading related entities will be specific for each type. I am still thinking over the possibilities with this but I think this is a better design, and the above design was coupling too much to an abstraction that is not necessary yet.
Here is what the repository interface looks like in the application core:
This is the implementation, it is still a good example of the logic for handling the ordinal positions in this situation with EF Core (the query to get the ordinal position to check if it has changed in an update must be non-tracking):