The Generic Repository pattern in C# is a design pattern that abstracts the application’s data layer, making it easier to manage data access logic ...
For further actions, you may consider blocking this person and/or reporting abuse
EF Core itself largely implements the repository and unit-of-work patterns. If you're using EF within a project, wrapping it inside another generic repository layer adds little value and is mostly pointless abstraction for the sake of abstraction, especially if it's just a basic layer that just calls EF's DbContext and DbSet equivalents (which lets be honest, is most of them).
One of the major benefits of using EF is to eliminate the need to write much of the traditional DAL boilerplate. I stopped writing custom repository layers inside my .NET projects utilizing EF years ago and will never go back.
There can be use cases for it but 95% of the repository layer implementations I've seen that use EF under the hood were almost entirely pointless.
Agree with your statements but the idea is for consistency when a diverse team of developers come together to write code with different styles. If we took say working with Dapper as an alternative this would be better suited to this repository pattern rather than just show EF Core.
For the record I expected comment like this.
I have to agree that Repositories are greatly overrated and to abstract EF the value it adds is close to none.
More so, Generic Repository is even worst. Yes, it can save development time, but if you tables with millions of rows, exposing Get all's without mandatory filters or paging can throw a (junior) developer off.
On saving (write) you can get way with with but on Query (read), Each entity has its own way of being queried.
A great alternative is encapsulating queries on their own objects. Used it on one project and looked really cool. If you don't want to create your own, see Ardalis specification package. Really cool stuff
Well, I don't really get your point. I use the generic repository pattern in order to avoid writing always the same crud codes for every repository. And if I need some custom method, then I add it to the corresponting repository and implement it. And I go a step further, because I use also a generic service for calling the repository methods. Which means, if I have a bunch of models (entities), where I need simple crud operations (and honestly this is the base of most applications), I just have a new repository and service with just some line of codes. Which I can extend later, whenever I want.
Thanks for your thoughts.
Good document. But in real life atleast all my projects never had to use this kind of generic repository with so many CRUD only functions.
Anyways any application which needs CRUD(normally it is most often used in hobby projects), this repository pattern is really useful and needful.
Agree with your statements but the idea is for consistency when a diverse team of developers come together to write code with different styles. If we took say working with Dapper as an alternative this would be better suited to this repository pattern rather than just show EF Core.
For the record I expected comment like this.
Agreed. Other ORMs doesn't have this kind of patterns built in.
But my view was do we really need this in real life application? I am developing 10+ years but hardly needed so many functionalities .
I've been a developer for 30 plus years and have used it on four projects with teams of ten developers each time.
That proves my point mate. 30+ years and just 4 projects. You just replied the ratio and chances of usage.
Moreover you may not agree on my points. That's totally acceptable. But there should be a window to be a listener.
I am out of this topic.
Thank you 🙏
Yet I know those developers have moved on and most likely took this practice with them. Personally I have only used this with Dapper. I've not used it with EF Core because the majority of my contract work is Cold Fusion.