That works better

Same here, combined with unit of work so you have the save changes async not in the repository itself.

But wouldn't you end up in having too many repositories (per entity) if each of it inherits from a parent class? E.g. imagine if you have repositories that do basic CRUD operations and inherit from a generic repository, you will be left with a lot of potential repositories that has not much to offer since you will also create a service per entity to implement your business logic (using the repository). What are your thoughts @MilanJovanovicTech? How can we avoid this in an architecture like the union one. I understand the principle of reducing code duplication, but it seems to me a bit overkill.

Tbh not really. I've had a huge battle with my team against repositories in my current project which unfortunately I've lost due to links to some MS docs from 2012 (where MS was showing repos). 1. If EF has some massive bug than it will get fixed ASAP. Like really ASAP this stuff is used tens of thousands of projects across the globe. You will have far much easier time upgrading the EF Package than rewriting your repositories. Which leaves us with only other valid scenario which is changing ORMs and how likely are you to do that. 2. Also if we are using ORM most likely we are also going some kind of DDD. That means you should only use EF to either retrieve aggregates which are (should) be build using the same method or to make a non tracking query to database. In second scenario what you end up doing is writing a query against the Quarriable which you may need to rewrite in case of an ORM Change.

EF bugs etc was just an example, there could be many reasons causing you to switch out your provider or ORM or whatever you happen to be using. One major thing I can think of is consulting work for example... If let's say you used dapper when you implemented the project, but after handing it off to your customer, their team doesn't like dapper for some reason and they want to use something else. Having a repo in this case makes things much easier to swap out, without risking changing other pieces of code that really don't need changed. The biggest thing here is code duplication/separation. in the chance you need to switch something out, and risk changing code logic that you don't really need to change, when all you really want is to update how you perform a database query. Even if you were to not use a repo pattern, and let's say you create some kind of a factory for your queries to avoid duplication, you're still basically implementing a repo pattern here, nothing's really changed. But like I said, I am NOT against not using repos, there are other drawbacks to using repos, I just don't think the given example is realistic in terms of an implementation without a UoW, which in my opinion is required for a proper repo implementation

The repository pattern won't save you from a DB provider rewrite...

Usually, I'm using the Generic repository as a base class, I'm not exposing the AsQueryrable as public. so What I do in your case is I create one Method in orderRepository to get a single item, and in the implementation, I use a Generic repository, but in OrderRepositoy we only see the Insert & Get Single Item, so in my perception, we can't use a generic repository like that, expose all method but it depends on how you design your structure code. like @A alddin said the biggest concern for me is the duplication/separation code, so if you need fast you can work directly in EFContext, but if you need maintenance the code, and in the future maybe you need to adjust the method to do a performance, you can re-write the single item use like (dapper/native command) and in all logic will be changes

You're very welcome!

Yes, I'd use UnitOfWork in that case

I couldn't agree more

I'd like to know more about this, I currently use it as abstract base class with virtual methods which then typed repositories inherit from

yeah me too, this isn’t how I implement generic repository, when I have several derived classes I implement unit of work to take care of the transaction

@@kimfom same idea here, the implementation in video seems weird enough. Not creating concrete derived repository class inherits form the GenericRepository make it mostly impossible to write any specific query related to that repository without uselessly expose IQueryable type from the repository

@@carmineos same, works perfect.

There's no way to make this work 😅 Either go the Specific repository route, or just use EF Core

@@MilanJovanovicTech Generic repos are totally fine from my experience. It can look like: _repoA.Add(a); _repoB.Delete(b); _unitOfWork.Save();

@@anvogel99 exactly like this

@@MilanJovanovicTech well.. A lot of projects use a unit of work, its pretty common. Its easy to combine with the aggregate pattern for example

​@@anvogel99 why not ? efCorecontext.Set().add efCoreContext.Set().add and call the save in Unit of work, or you can combine all in a manager class which is a unit of work. efcore eb context already provides a very powerfull generic implementation and a perfect lambda query builder. why should I wrap that perfect wrapper again

Can you add a link?

Database-first is a good argument for using it

That's all right!

I'm glad you enjoyed it, Emanuel :)

I've seen that idea float around, I might explore it in another video

But what's the value of a generic base class in a specific repo vs. just using EF Core?

@@MilanJovanovicTech the specific repo inherits from the generic to reduce boilerplate and keep a base consistency that can be overridden when needed. The reason I don’t use dbcontext directly is mostly for testing, but also for consistency of use as mentioned before and other benefits that you get out of a repo.

@@pdevito testability is important, I was agreeing in the video but I remember testing.

Because they don't call the database

That's not really changing infrastructure. Just changing data access mechanism.

@@MilanJovanovicTech yep, that's what I meant

I read some article talk about that, and I like a words:( avoid abstraction of abstraction )

Why not just use EF Core at that point since it offers all of that without an abstraction?

@@MilanJovanovicTech because i want to keep the application as clean as possible. Im also starting to implement ddd as much as possible and this will also help to keep the repos more clean. I use the repos to fully separate the logic. But i have a question for ddd. How to implement aggregates and all this stuff when you work with lists in lists and so on. I have a big entity with many lists in it and other props and many other entities

I guess because we've learned about the importance of inversion of control, clean architecture, interface segregation etc

@@flobuilds Let me understand, to keep thing clean you encapsuate a repository (EF) with units of work in an repository with units of work? How is that clean?

I also hard to learn that the hard way

Make the repository specific, and only return what you need. Are you ever going to change the DB engine, really?

@@MilanJovanovicTech but making specific repository for each command/query will produce many files beside duplication, what do you think? There're specification pattern, looks like a solution? Yes, I might change db engine, may be use non relational db for reading and relational one for writing, what do you think?

The runtime will take care of disposing

How does Generic Repository as a base class differ from just using EF Core?

@@MilanJovanovicTech the generic repository is an interface. And in the IServiceCollection i dont use the generic , i use the entity interface

Glad you enjoyed it!

There's benefit for unit testing, yes. But is there value in unit testing the DB?

It does

No difference

It will suck less 😁

It does go against CA directive. I will sometimes be pragmatic and break this constraint.

Here you go: kzfaq.info/get/bejne/ht6ojcaFp7_NY2g.html

VS Dark Theme + ReSharper color highlighting

Thank you so much

I like it for testability

You understand!

We would have it, typically

Then you're not doing a generic repository, but a SPECIFIC one. With a generic base class.

I can't like this enough. Including IQueryable would trigger a "Requested Changes" action from me during a PR review. :)

That's the whole point. there is no use of a generic repository if you are going to expose IQueryable. It would be a useless wrapper

If that's the case, why even use a repository. Just use EF

That's a specific repository with a generic base class. Why not just use a Specific repository with EF Core in the implementation?

Hopefully you won't use it on a large table 🤣

How does that work?

@@MilanJovanovicTech I created extension method for middleware configuration where I retrieve properties form DbContext, iterate over collection and create, register generic repositories. I think it is quite useful as long only EF Core is used as data source provider

This is just an argument about generic repositories. In most cases where you are dealing with so much data, you will write very specific queries that will be optimal from a performance standpoint. You can then decide if you want those to be part of the repository.

That's pretty much the Specific repository pattern, with a base class... At that point why not just use EF Core directly in the Specific repository?

I like the "specific repository" that just exposes the methods needed, and under the hood uses EF Core in the implementing class

What is the value of unit testing the DB?

@@MilanJovanovicTech That is the point with your "anti pattern" rant. You do not test the database, you test the consumers of the repository to do the right stuff and you are directly depending on EF Core, which is a maintenance nightmare (Microsoft doesn't give a F*#! about breaking changes). Not defining an interface that decouples desired behavior from the implementation is just a quick & dirty approach. Inversion of Control gives the need to abstract the behavior your system is depending on, if you do not understand this, then maybe you should not create "tutorial" videos. The next thing that is absolutely not addressed in this video is that it is necessary to separate models. Using database models as domain entities and throwing these entitites out of your controllers as json results is not only bad practice, it is just plain wrong in the long run. Did this years ago like everyone else and ran into really ugly bugs because this pattern enforces an anemic domain model and - and this is the worst part - mutable state wich will be changed by some weird service that only exists to encapsulate business logic. This makes testing quite impossible because you not only have to test the happy path, but also all illegal invariants of an entity. This is just impossible because it will lead into an 2^n problem really quick, depending on the complexity (amount of properties) and variants (data types used for these properties). All in all, i would argue that or mappers like EF Core are the anti patterns, but microsofts marketing and the lack of good education of most developers let's people thing that they are somehow "necessary" and make your life "easier", which they just do not do. They bring more complexity and opaqueness of how your system works. Not separating models, not abstracting behavior you depend on and throwing third party libraries throughout your application will lead to unmaintainable, hard extendable and painful to test big balls of mud to be considered as legacy when being developed. Please do not do this. Do not make each layer depend on some third party library and make your layers clean by using the lowest language levels you can. There will always be some dependency like the programming language or framework, but good software architecture will reduce this to a minimum, making your business application easier to extend, easier to test and agnostic from third parties and their weird roadmaps. This is a win in the long run (believe it or not, software systems will run for a long time, once they are finished), and here I am speaking about decades. And nothing is more painful than making a change in a software that was poorly designed.

I just called it 'specific repository' and I think that's a fine approach, since you're only exposing aggregates

I'm enjoying more and more using EF Core directly

Downside I’ve found to direct EF is testability. Usually leaning on integration tests where it’s moot, but in instances where you do need to use a unit test, dbcontext adds a lot of complexity and pain.

​@@pdevitoi think you can create and use interface IApplicationDbContext. In that way, it is easy to mock and unit test will be easier to implement.

You can also mock EF Core?

Tell us how!

I like the repository, but not when it's done like this

@@MilanJovanovicTech I just saw it implemented as “clean architecture”, don’t know what to think at this point.

At that point I'd just the specific repository, which is better imo

Row Level Security? 🤔

@@MilanJovanovicTech effectively. What we do depending upon perf (and ef 8 likely fixes this with pre compile of queries) is either use a TVF that can be inlined and takes the user id as a parameter for all of our get/lists and have a SecureList extension method on every DbSet. (If it is small we use chained linq where clauses that use predicate builder). We do the same for SecureDelete, SecureInsert and SecureUpdate. In the past that got a wrapper around EF core but now I just use extensions. But it still isn’t a great solution because I want my devs to have to work hard to do any of those things without applying security. It should be the default condition that everything has to go. Through the security checks and rare that they don’t. So I see repository like you outlined as what people do to fix that they can’t extend dbset and inject the ClaimsPrincipal and then override all of the methods and create their own insecure ones that require hoops or at least a Boolean of “yes I really mean bypass security.”

Great, now you've got a method that's far more complicated to work with than LINQ

There isn't a lot of value in unit testing data access logic

Unless you do

If you're using a 'specific repository' that inherits from the generic one, and the generic repository uses EF Core for example. Why not just use EF Core directly at that point inside the 'specific repository'? If you want to reduce repetition, add the generic methods in the DbContext.

@@MilanJovanovicTech Sure, you could do that. You could find many ways NOT to use a generic repository. Using a generic repo means I don't have to write a specific repo each time when all I need is simple crud on the entity. It's also much cleaner, more readable code. It's also really simple for unit tests. I've also had scenarios where this abstraction allows me to extend certain functionality easily. Sure, everyone has their own preferences and opinions, and you are entitled to your own. I just don't agree with it being labeled an anti-pattern and "Why it sucks" when the advantages are clear, when a complete implementation of the pattern is done. I challenge you to challenge yourself on this, and build your own complete implementation. I enjoy your videos, I just don't agree with you on this.

When would you consider it too much?

@@MilanJovanovicTech When I choose N-Tire.

Because they don't do anything - just add the entity to the ChangeTracker

It's not perfect, but it can be useful

It could be, but you'll run into issues with Identity Map / Change Tracking support

That's even more of a mess 😅

Could you elaborate?

I get the argument. But not much value in that - you're still the one writing the code 🤔

Me and my colleagues are communicating through code. Someone who is searching for, but not finding a repository for a certain entity, might wonder why, and look up how the entity has been used in other circumstances, and then learn that it is part of an aggregate!

That’s our use case as well indeed. Because we have a guideline to use repo’s rather than dbcontext directly, devs can not easily write entities that shouldn’t be written directly. When they do all the workarounds to do it anyway, then at least it’s easily picked up on in the pull request.

IService 🤮🤮🤮

If you ever try to couple more than one DB provider in a single unit of work, you're in for a world of hurt

Do you have a demo implementation?

@@MilanJovanovicTech Nop. I tried to test your idea in a new project. it works perfectly and It seems you are right when we are sure we don't need to change ef.core but who knows if a bounded context representing a micro service needs to change its persistance mechanism in future? I think above suggestion covers both parties. application layer is independent of ef core technoogy and we don't also repeat ourseves over and over in every repo or make a generic wrapper repo.

With or without a generic repository?

@@MilanJovanovicTech , with Generic Repository. I have the basic CRUD operations and use my services as my unit of work.

I'll check out Sqlkata, sounds interesting

What are you adding on top of EF with the wrapper? Nothing... Hence why it's pointless

It's a great combo, but I don't like the UoW idea with repository properties. This video was basically an argument against "generic" repository. I also have a "specific" repository video that aligns nicely with the one from Mosh

@@MilanJovanovicTech Thanks. I'll check out your other video. What's wrong with repository properties in UoW?

Haven't tried it

@@MilanJovanovicTech Can you make a video regarding SQL Sequence and EF?

I like the suggestions!

@@MilanJovanovicTech Thank you 😉

How would you do generic repository with Dapper?

@@MilanJovanovicTech The repository is pretty much the same as you did in the video without the SaveChanges method. I previously used Dapper.FastCrud to write the methods easier since you can pass in the type of the entity you're querying but it's also possible without FastCrud aswell, it just gets a little bit trickier.

If you search for "generic repository C#/.NET" - something like this pops up. That's why I used it for the example. What you are talking about is something entirely different, which I very much agree with.

I talked about the Specification pattern before

@@MilanJovanovicTech need to catch it up :) thanks :)

It's a topic that will forever be love/hate for .NET devs

Did you even hear the sentence after that? 😅

@@MilanJovanovicTech Nah. Visual learner

I'll agree. But you probably don't make it a generic repo with Dapper

I've seen worse implementations than this one in the wild

Yes

There's always extension methods, static classes to solve duplication. I like the benefits I get with MediatR. What else?

Should I talk more about things I disagree with? 🤣

I covered specification pattern in another video, no beef with it

That approach makes sense. Maybe I need to record another video?

@@MilanJovanovicTech maybe

Things blow up

Probably the opposite of that makes sense

What's the point of Specification then if you'll just return IQueryable? 🤦‍♂️

It should. This is how a lot of people do it.

@@MilanJovanovicTech Yeah, that's just cargo culting. Not ever layer of indirection actually brings value, but they always bring complexity.

It's never too late to start

Oh crap

As if the generic repository wasn't enough, you'd slap a Specification on it? 😅

1. Remove all the methods from IRepository and add one for the specification pattern 2. Add IUnitOfWork interface and implementation + Unit testing is easier + Queries are reusable - Added complexity

@@z0n_ Or move save changes to IAppDbContext

Yup

Supposedly

Shouldn't we treat different databases... differently? They're powerful tools. If we abstract too much, we risk losing all these awesome features.

that's true indeed.

How so?

@@MilanJovanovicTech In your unit of work you should have access to your derived repositories then along with one save changes method and probably implement IDisposable then you add this unit of work to your service container, when you need to persist data you will inject only the unit of work and the service container will resolve the repositories. So you can now just use the unit of work to interact with the two data models and call the unit of work’s save changes… I hope I’m not confusing you 😅

What's the value of unit tests for the DB though?

@@MilanJovanovicTech true, we have a couple… but they would be better written as integration tests to be honest

Why not just use EF Core if you'll go through all that trouble?

Fair enough

- EF Core - Specific repository

​@@MilanJovanovicTech thanks ❤

That's even more of a mess 😅

I have other videos covering different takes on the repository pattern

Not how I'm describing it here - check my more recent video about this.

Not really 🤷‍♂️ But the way I implemented is 💩

@@MilanJovanovicTech Can I use generic repository in microservice?

How does Generic Repository as a base class differ from just using EF Core?

@@MilanJovanovicTech No difference. In fact, EFCore DbContext uses in-built Unit Of Work. UoW's multi repository operations allows devs to focus more on the domain logics. Again, this opinion supports architecture that is purely CRUD driven with basic verbose APIs. Not DDD.

You can always create more accounts 🤣

What's the added value of using GenericRepository vs. using DbContext.Customers?

@@MilanJovanovicTech usually all of benefits from using repository pattern: isolated testability, common abstraction for switching orm/ database, exposing ports for Infrastructure's adapters,... plus the benefits of GenericRepository: saving duplicated CRUD code for any CustomerRepostiory/ UserRepository that inherit it.

If you advice is don't overengineer, then why not use the simplest tool for the job?

@@MilanJovanovicTech Good point, but the tool we are talking about is not simple (EF core). As a driver of a car you dont need to understand whats inside the engine. But as a mechanic you have to solve problems that have to do with engines (or replace the whole damin thing :D). If you install an engine that you dont understand, you could get problems you dont understand. To use EF core is easy at first glance, but hard to master in many ways. What i was pointing at with overengineering was the fact that you say "use EF core instead of a (generic) repository because its easier". But then you (as a developer) depend on another external tool thats maybe not necessary because its more complex than just to have a raw and plain repository that writes SQL against a relational DB. I also like to use EF Core + LINQ because it totally fits into modern language of C# (with declarative approach). But its not easier! It requires knowledge about LINQ, you need to read Logs to see if the SQL performs bad, you need to have a clear Model (not a domain model, but a data model that reflects your db table), you need to know about lazy loading and eager loading, and so on.

@@sotsch9280 "If you install an engine that you dont understand, you could get problems you dont understand." - the same applies for Database engines 😁 No ORM will save you from having to know SQL and how to use a database.