Replies: 3 comments
-
One reason (on the top of my head) to keep a repository interface is when you want to work with the specification pattern... But you're right, for many uses it is overkill, especially as ef core is much better geared as a repository and unit of work then ef6 was (and towards testing as well). I personally wouldn't mind getting rid of it... but I think implementing tests is of a much higher importance, and should happen first anyways, so we can see what differences it makes towards that as well. |
Beta Was this translation helpful? Give feedback.
-
IRepositoryAsync is made just to remove the dependency with EFCore packages in the application layer. It's more of abstraction towards the ORM. If in case, there is a need to switch to another ORM, it makes sure that the application doesn't have a direct dependency with Entitiy Framework. |
Beta Was this translation helpful? Give feedback.
-
Yeah, but that's the thing, nowadays (and even before) it doesn't happen that often that one changes its ORM mid-flight, especially if the ORM in question already has a nice abstraction and supports multiple different databases... So the question is... is it worthwhile to have to maintain that code and deal with the extra complexity just for the very small chance that you would want to switch out your ORM at a later date (which probably would be quite some work anyways, having the extra abstraction layer or not). |
Beta Was this translation helpful? Give feedback.
-
What is the value of the IRepositoryAsync interface?
Why not directly add the AppDbContext (or an Interface IAppDbContext to keep the DbContext in Infra) into AnyService.
I believe that the DbContext is a Repository and Unit of Work by itself. Why add another Layer which is hard to work with?
Any thoughts on that?
Beta Was this translation helpful? Give feedback.
All reactions