❔ is Generic Repository a bad implementation of Repository Pattern?
Surfing the internet I have found several articles that say it is an anti-pattern because it is an abstraction of an abstraction. In a personal project I implemented the generic repository to avoid repeating code that is normally used in CRUD and if I need more specific functions I create a new interface and implement it. Should I remove the generic repository and create a specific repository for each database table even if I need repeat the code of a CRUD?
40 Replies
Entity Framework is a generic repository
is this on top of Entity Framework?
So, yeah, it makes no sense to abstract a repository with a repository
or on top of something like ADO?
Outside of EF, tho, it does make sense
I forgot to say that I'm using EF, but thanks for yours replies
yeah, in that case it's doing lots of harm and zero good
the database context is already both a repository and a unit of work
Ok, thanks
As you pointed out you will find various debate on this topic,
Ive been down that rabbit hole too, and been seaching the internet thin for answer
According to Steve Smith - Ardalis Ms MVP and ASP, RP is not bad used with EF, Same with Mosh Hamedani , and I agree with them. Here are some source you can watch and read on
https://www.youtube.com/watch?v=rtXpYpZdOzM&t=585s&ab_channel=ProgrammingwithMosh
https://www.weeklydevtips.com/episodes/024 And I ended up agreeing with Mosh And Steve. Here is mt perspective 1. RP is a design to implemented different ORMs or Data access technology, where EF is a ORM technology with that said I think we can conclude that its not the same. 2. Minimizes duplicate query logic, EF can return Iqueryable and you will with time have a lot of Iqueryable around your code because of incl. and thenIncl. and etc. Where RP can encapsulate those query and should 3. Decouples application from persistence framework 4. Testability ( look Ardalis article i linked ) And heres too why some may think its an anti pattern - "The repository pattern is a design pattern that provides a centralized approach to access data from a database or any other data source. It acts as an intermediary between the data source and the application, providing a unified API for accessing the data. While the repository pattern can provide many benefits, such as separation of concerns, decoupling of the data layer, and a clean API, it is considered by some as an antipattern in certain contexts. Some developers believe that the repository pattern can introduce unnecessary complexity and can lead to tight coupling between the application and the data layer. Additionally, over-reliance on the repository pattern can result in an anemic domain model, where the majority of the business logic is located in the data layer, rather than the domain layer. In summary, the repository pattern is not inherently an antipattern, but it can become one if it is used in an inappropriate manner or if it is applied blindly without considering the specific context. "
https://www.weeklydevtips.com/episodes/024 And I ended up agreeing with Mosh And Steve. Here is mt perspective 1. RP is a design to implemented different ORMs or Data access technology, where EF is a ORM technology with that said I think we can conclude that its not the same. 2. Minimizes duplicate query logic, EF can return Iqueryable and you will with time have a lot of Iqueryable around your code because of incl. and thenIncl. and etc. Where RP can encapsulate those query and should 3. Decouples application from persistence framework 4. Testability ( look Ardalis article i linked ) And heres too why some may think its an anti pattern - "The repository pattern is a design pattern that provides a centralized approach to access data from a database or any other data source. It acts as an intermediary between the data source and the application, providing a unified API for accessing the data. While the repository pattern can provide many benefits, such as separation of concerns, decoupling of the data layer, and a clean API, it is considered by some as an antipattern in certain contexts. Some developers believe that the repository pattern can introduce unnecessary complexity and can lead to tight coupling between the application and the data layer. Additionally, over-reliance on the repository pattern can result in an anemic domain model, where the majority of the business logic is located in the data layer, rather than the domain layer. In summary, the repository pattern is not inherently an antipattern, but it can become one if it is used in an inappropriate manner or if it is applied blindly without considering the specific context. "
Programming with Mosh
YouTube
Repository Pattern with C# and Entity Framework, Done Right | Mosh
🔥Get the COMPLETE Entity Framework course (80% OFF - LIMITED TIME): http://bit.ly/2rZAgrD
Want to learn more from me? Check out my these links:
Courses: https://codewithmosh.com
Blog: https://www.programmingwithmosh.com/
Facebook: https://www.facebook.com/programmingwithmosh
Twitter: https://twitter.com/moshhamedani
Confused about the reposito...
Simplecast
Do I Need a Repository? | Weekly Dev Tips
This week we'll answer this extremely common question about the Repository pattern, and when you should think about using it.
are they talking generic repos or non-generic ones?
Because a generic repo does
which is nothing more than just a useless passthrough method
if you have specific repos that add value, then those make sense
like in my discord bot, I have a PromptService that's really a repo
when you do things like AddPrompt it will check that the active user has permission to do that
Im not sure i quite understand generic repos? is that just BaseRepository with generic methods
it's like what @Angius just posted
identical behavior across all types in the database
i see then yes
identitcal behavior across all entities
Then it's useless
you need to have that BaseRepository otherwise you will end up writing the same code for all repositories
DbSet already has .Find(), why wrap it with another .Find()?because it returns iqueryable and a repository pattern should not return iqeryable
uh
No it doesn't
eg, here's one of my repos https://github.com/jcotton42/spear/blob/main/src/Spear/Services/PromptService.cs
GitHub
spear/PromptService.cs at main · jcotton42/spear
Contribute to jcotton42/spear development by creating an account on GitHub.
.Find() returns the given itemaaah my bad 😄
i was a bit too fast on the keys i was stuck on incl from previous post
i need to find all my old sources to come up with answers
Sure
it has useful, specific, behaviors like authz checks, caching, etc.
But so far the only arguments in favour of generic repos over EF I heard are "abstraction good" and "what if I want to change the database, the provider, and the whole dev team one day?"
One of the arguments that i think is valid is that if you want to use multiple ORM technologies
at the same time?
yes
against the same database and entities?
I can't think of why you'd want to do that
Ig some people use EF for insertions and updates, and Dapper for querying
if you suddenly need to use a nosql db or the otherway around i guess , i havent implemented it myself
or as z porinted out
That's easily rebuked by "YAGNI"
that's going to involve radical changes to your data structure
you don't just switch from relational to non-relational without large changes
they're completely different paradigms
Just use Postgres and have the best of both worlds 
I think we should stick to the topic 🙂
Sure
" Should I remove the generic repository and create a specific repository for each database table even if I need repeat the code of a CRUD?" The answer is NO because you will end up violating DRY principle
But, yeah, if you want to swap a database out, chances are you'll end up needing much more changes that swapping out what repo you use
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.