This is a discussion I've been going over a lot of times already. My takeaways so far: - A generic repository is useless. It always ends up as a kind of proxy to EF Core, and you just keep adding obscure flags and delegates to the method parameters. This is a horrible kind of repository. - The testability argument is also a very dangerous one. If your unit tests which do not want to use a proper DB are tightly woven together with DB queries, then it might warrant a refactoring to make the functionality more pure without requiring a lot of dependencies. However, especially when dealing with CRUD, you are probably much better off using integration tests with a real database running in a testcontainer. The best use of mocks is for unmanaged third party dependencies, and a database is usually an integral part of the application, not an "unmanaged" one. I pretty much entirely only test with test containers for my DB. Mocking a DB or using in memory dbs will either tie your tests to your repository, which runs into the issue of refactoring fragility, or your Expression trees will result in very different queries than those ran on a proper DB. - I find the DB persistence argument a bit weird. EF makes it easy to swap relational technologies, but I think moving from Postgre to MSSQL is likely not the main scenario behind that argument. People argue that you can easily switch from SQL to NoSQL by using a repository, but I've 1) never seen that happen in a project, and 2) I'm convinced that it is not possible to abstract the relational nature of SQL in such a way that you can simply change in a MongoDB which does not support native joins without the implications spreading way further into your app, up until the API layer. Relational databases are usually a good default taking you a looong way, and when you run into the situation in which you want to move to a NoSQL technology, then there will be many more challenges than swapping your DB tech. However, when people discuss about this topic, they often talk different things. If you use EF Core, that's your repo. What is usually built on top of EF is not necessarily a repo, it's more of a data access service, which provides reusable queries, reusable logic for e.g. auditability trails, caching and so on, as well as model entity mapping. The "EF is your repo" crowd is often quick to dismiss that this can be very beneficial to have in a dedicated class. Yes, there are specification patterns you can use, you can also use an extension method for query reuse and model mapping, but often you might run into a situation where the concerns of making a query reusable requires additional dependencies. And in this case I can warrant a Data Access Service / "Repo" on top. It's just not a black and white thing. So, my takeaway is that the truth is somewhere in the middle. There are a lot of use cases where you do not need a repo, but there are very valid use cases to use one as well. Well, as long as it's not a generic but a typed repo, that is.
I agree. The choice of patterns and technologies should be driven by their fit for the problem at hand rather than their popularity or perceived best practice status. The Repository Pattern is a tool, not a dogma. Be wary of generic repositories that become proxies for underlying data access frameworks.
In theory , repositories allow easy switching between databases (SQL vs. NoSQL). However, it's unrealistic. Changing database paradigms is non-trivial. It often necessitates changes throughout the application, not just at the repository layer. The relational nature of SQL databases involves concepts (like joins) that do not translate directly to NoSQL databases. The idea of swapping out one for the other without significant implications elsewhere in the application is challenging. However hard you try to limit the leakage outside of the repository layer, such changes are non-trivial and have wide-reaching impacts.
@@kelsey_roy Without limiting the leakage, you just throw out the entire application and lose hours of work. Also a change in database does not mean a change in paradigm. Adding a redis cache is technically a change of database. I use repository pattern to push performance updates to further out tickets. It also helps avoid issues when another team is modifying something you are directly interfacing with. The reason i would say use a repository for anything external from your application is because you don't know what is going to be down the road for your project. A little pain now can avoid extreme pain later.
You're already married to an ORM no matter what. The hard part is to rewrite thousands of queries in a new syntax, plus to find substitutes for every SINGLE special feature your ORM had. More abstractions means more bugs.
Certainly there will always be effort but it is a difference whether a change is rather local to a component or spread all over the entire code base, isn't it?
This is a discussion I've been going over a lot of times already. My takeaways so far:
- A generic repository is useless. It always ends up as a kind of proxy to EF Core, and you just keep adding obscure flags and delegates to the method parameters. This is a horrible kind of repository.
- The testability argument is also a very dangerous one. If your unit tests which do not want to use a proper DB are tightly woven together with DB queries, then it might warrant a refactoring to make the functionality more pure without requiring a lot of dependencies. However, especially when dealing with CRUD, you are probably much better off using integration tests with a real database running in a testcontainer. The best use of mocks is for unmanaged third party dependencies, and a database is usually an integral part of the application, not an "unmanaged" one. I pretty much entirely only test with test containers for my DB. Mocking a DB or using in memory dbs will either tie your tests to your repository, which runs into the issue of refactoring fragility, or your Expression trees will result in very different queries than those ran on a proper DB.
- I find the DB persistence argument a bit weird. EF makes it easy to swap relational technologies, but I think moving from Postgre to MSSQL is likely not the main scenario behind that argument. People argue that you can easily switch from SQL to NoSQL by using a repository, but I've 1) never seen that happen in a project, and 2) I'm convinced that it is not possible to abstract the relational nature of SQL in such a way that you can simply change in a MongoDB which does not support native joins without the implications spreading way further into your app, up until the API layer. Relational databases are usually a good default taking you a looong way, and when you run into the situation in which you want to move to a NoSQL technology, then there will be many more challenges than swapping your DB tech.
However, when people discuss about this topic, they often talk different things. If you use EF Core, that's your repo. What is usually built on top of EF is not necessarily a repo, it's more of a data access service, which provides reusable queries, reusable logic for e.g. auditability trails, caching and so on, as well as model entity mapping. The "EF is your repo" crowd is often quick to dismiss that this can be very beneficial to have in a dedicated class. Yes, there are specification patterns you can use, you can also use an extension method for query reuse and model mapping, but often you might run into a situation where the concerns of making a query reusable requires additional dependencies. And in this case I can warrant a Data Access Service / "Repo" on top. It's just not a black and white thing.
So, my takeaway is that the truth is somewhere in the middle. There are a lot of use cases where you do not need a repo, but there are very valid use cases to use one as well. Well, as long as it's not a generic but a typed repo, that is.
I agree. The choice of patterns and technologies should be driven by their fit for the problem at hand rather than their popularity or perceived best practice status. The Repository Pattern is a tool, not a dogma. Be wary of generic repositories that become proxies for underlying data access frameworks.
@allinvanguard thx a lot for your huge contribution to the topic and the discussion - very valuable thoughts 👍
God bless such sanity.
Never go without this abstraction ever. You don’t know if one day the sql db might become a graph, block chain, or a form of proprietary db.
In theory , repositories allow easy switching between databases (SQL vs. NoSQL). However, it's unrealistic. Changing database paradigms is non-trivial. It often necessitates changes throughout the application, not just at the repository layer. The relational nature of SQL databases involves concepts (like joins) that do not translate directly to NoSQL databases. The idea of swapping out one for the other without significant implications elsewhere in the application is challenging. However hard you try to limit the leakage outside of the repository layer, such changes are non-trivial and have wide-reaching impacts.
@@kelsey_roy Without limiting the leakage, you just throw out the entire application and lose hours of work. Also a change in database does not mean a change in paradigm. Adding a redis cache is technically a change of database. I use repository pattern to push performance updates to further out tickets. It also helps avoid issues when another team is modifying something you are directly interfacing with. The reason i would say use a repository for anything external from your application is because you don't know what is going to be down the road for your project. A little pain now can avoid extreme pain later.
You're already married to an ORM no matter what.
The hard part is to rewrite thousands of queries in a new syntax, plus to find substitutes for every SINGLE special feature your ORM had.
More abstractions means more bugs.
Certainly there will always be effort but it is a difference whether a change is rather local to a component or spread all over the entire code base, isn't it?
Divorces are usually messy.
What is the difference between Repository Layer, Persistence Layer, and DAO Layer?
In most cases these are all referring to the same layer
In .NET world, it’s called the DAL - Data Access Layer.