You say that your CourseRepository knows nothing about EntityFramework, however, it is strongly coupled to EntityFramework, because it's base class, Repository injects a DbContext, which is EntityFramework specific. If you remove the `System.Data.Entity` reference, and swap it with another ORM, the whole things breaks. So it's wholly dependent on EF, from the generic base class, upwards. You should really name your generic repo as `EntityFrameworkRepository`, to show that it is dependent on EF. But this will still mean the app breaks when you swap ORMs. It would just make it more clear, as to why.
Mosh, I don't know if you still read this but I wanted to say THANK YOU for taking the time to go over the arguments that EF already implements the repo pattern, etc etc, and demonstrate that this is not exactly the case. This entire debate had me so confused for quite a while, and you did a _great_ job putting it to rest (for me, at least). The demonstration is also nicely done. Thanks, really.
I have done repository before and I am new to unit of work. My repositories have save and delete methods. The way you explain unit of work here has helped me a great deal I will be implementing this pattern much more often.
I've listened to many Mosh tutorials over the years, and this one is still the most impressive to me... he says the same things as many other videos, but the cadence along with the presentation queues simply flow better here. It's why I've come back to listen to it repeatedly... it's also superior in quality vs an average college lecture.
Find method in IRepository is breaking the rules of having the query written only once. A developer can inject any expression in it duplicating queries in different repository clients. I'd remove it from the interface and allow only named query methods. Specification pattern might be an alternative option but that in the end kind of boils down to the same thing.
I was searching 2 days for guide like that and everything was a trash, lessons without understanding the base... and only now youtube proposed me this video and it's perfect!!! My huge respect to author !!! Like and subscription :)
Nice video. I tend to find for smaller projects Entity Framework is just fine for a repository and unit of work pattern as there is less if no duplication of queries. I have used your pattern before and found it to be too much for small projects. My only advice is: Do what is best for your particular project. There is no one size fits all solution. The solution posted in this video is great for a larger application.
I agree with you Mosh. Repository Pattern has become a mystery to me ever since I tried to explore it and for the most part articles from different developers have different implementations of Repository Pattern in which it is hard to determine which is actually the right one.
I was about to not use repo pattern on my project because of other videos saying it was redundant, but your explanation made so much sense and was really easy to understand, thanks for taking the time to make this video.
Abolutely brilliant! This finally made everything 'click' on using the Repository pattern with EF6. I'd avoided it because it seemed like far too much work for too little benefit vs. using DbContext directly,
Hi Mosh, Thanks for the excellent presentation. I have gone through many of the comments. Here are my consolidated queries. 1) Find method which takes a predicate as the parameter. Don't you consider this as a potential risk for leaking abstraction into layers depending on the repository a) not every Expression can be interpreted by EF b) there's no guarantee that a predicate which works with EF is going to work with a different data access library (let's take OData as an example) So the only solution here is to write Find method in each repository as per the requirement? 2) Since many of the RealWorld applications contain more than 100 Repository classes. It's now important to learn about bounded contexts in Domain Driven development so that we can architect a project by splitting it into different domain projects and use related bounded contexts. I have gone through several articles on this topic. But could you please prepare and post a video on it by covering all the concepts like (MVC, EF, DDD, BC, DI....) Because I think you are the best person who can explain the things in a clear manner. :) Thanks, Vinay
These is the best tutorial i have found that explains a concept i have been trying to grasp for the last 2 weeks. Very precise and explains everything in details.
Its a really amazing and simple explanation. Thanks Mosh. I regret taking a course at Naresh IT, Hydrabad. They wasted my time and money. Thanks again Mosh.
You're such an amazing instructor who can simplify the information in perfect way and make the listener understand well .. thanks Mosh and I hope you to share more videos and courses
IMO, the “collection-like interface” is the least important and most out-dated portion of the repository pattern. The most important part of the pattern is to isolate the rest of your application from the persistence logic. You typically don’t want to reuse repository methods. Since your business logic shouldn’t be in the repository, you don’t want multiple code paths reusing a repo method like SaveArticle(Article article). Instead reuse the same service method that calls the repo so the same business logic is enforced. Too many coders try to get cute/clever with generic repositories, exposing IQueryable, etc. EF performs poorly enough all by itself. It doesn’t need help being slower by the n+1 problems created by not writing custom linq queries that specify the include. Of course it always depends on the specific constraints of the application. Thank you for your great videos.
I think you should have touched a bit on ".AsNoTracking()" and perhaps also .Attach(), EntityState.Modified and EntityState.Detached, since e.g. retrieving all courses without intent to change anything, is probably the most common use case. Then you can just attach the specific course when you actually want to change it, i.e. have Entity Framework track it for you. If all retrieved objects are tracked all the time, it's a huge impact on performance.
When I do greenfield development I always do Controller -> Service(es) -> Repositories -> EF/DbContext (and/or MongoDb). This has been a very good pattern for me/us, as it's clean and very effective. Having a repository present two different database technologies as a single source, gives a lot of freedom to concentrate on the business logic and not the database implementation
Good video. Some things: 1) I think that the GetAll method is not so generic to be part of the interface and can be a little dangerous. Here where I work, many times people use the GetAll and then filter the results in memory (even when the original data has millions of rows). 2) I think that the Find method must hava a call to ToList (or AsEnumerable) before return the results, so an user can´t cast it back to IQueryable.
11:10 - 11:15: I personally think that your work is not wasted. When you have full separation of concerns you can re-use the logic very quickly in other apps even if their purpose is different. BTW, thanks a bunch for the video.
You say there is no need to update in the repository pattern. But, actually you do need to update records. Thanks for leaving out that extremely important piece of information!!
If you don't want to over complicate things with the unit of work, you can have a simple update in your repository like this: public MyEntity Update(int id, MyEntity newEntityValues) { using (var context = new MyDbContext()) { var entity = context.MyEntities.Find(id); context.Entry(entity).CurrentValues.SetValues(newEntityValues); context.SaveChanges(); return entity; } }
The video title says "Repository Pattern with C# and Entity Framework". Yet, you are adding complexity so that you do not have to use EF in the future. Not necessary for the first implementation of your repository pattern. You can still use testing frameworks to test your methods
Best video I've seen on this topic, and its easily understandable from what you mention and you give course materials! Looking forward to working through your Pluralsight courses.
I should advice from experience on two distinct projects which followed this idea of encapsulating EF within our own Repository + UOW: Don't do it! EF already does it and you could use Specification patterns to easily overcome the problem of repeating querying logic. Also, your entire application DOES NOT need to use only one ORM. It's fine to use EF for simple/non-performant areas/contexts and use something else like PetaPoco for areas where you need performance, etc. Another idea if you still want to have a class named Repository: Just make it a simple class where you inject the DbContext. It would sort of work as a decorator over the DbContext. On the two projects I've worked we followed this (IMO) contrived inheritance of BaseRepositoryClass + BaseRepositoryInterface + ActualRepositoryInterface + ActualBaseRepositoryClass inheriting from all of that: I have deeply regretted doing so. It is like CQRS when folks hear about: Let's implement it on all our system. No! Only do it for the relevant areas/domains/bounded contexts of your code.
the application in the video is just for a demonstration!
6 ปีที่แล้ว
What if id is type of Guid, then your generic repository will not work. Here is iEntity comes to play. Your domains should inherit from iEntity, so you can query based on id
I get it! And this is the first time it has really been made clear to me! I have been playing with the repository pattern for a few years now and have used it in several projects, with a degree of success but it always get messy when the project had to do tricky things or when the project got bigger. I would not end up maintaining the DRYness that I like. I could see the benefit but was still only really successful with it in small projects that I saved through calls in the interface as well. The way you use the UnitOfWork pattern is really cool! I'm also taking your Angular2 course on Udemy and you are great there as well! Thanks so much for your clarity! Irv
where've you been man i was searching for you thought :p as you said in the begging i've read a lot about unit of work and repository but i didn't get it clean and with this video you've explain it well thank you very much. it helps a lot, waiting for more from you.
One of the finest explanation of repository pattern with c# and EF. Thanks to you, I really appreciate the quality and content of the video. After reading many questions in the discussions section, I believe someone needs to address - how to overcome the challenges by Botond related to Find method, as well as, what should be the approach when an ORM gets changed? For example, later on, if we want to use Nhibernate instead of EF then what would be the possible changes
Mosh! Thank you so much for this video. I stumbled upon it when designing the architecture of a website I'm working on. I'd read so many conflicting views on why/not to use repositories with Entity Framework - most of them against using repositories for the same reason you said you've come across a lot, too. You've explained very clearly to me how it is beneficial, and I also picked up some tips on how to create some Generic repositories in future. Well worth a watch, and I'll be coming back in future to view more of your videos! Thanks!
One of the disadvantages of using the repository pattern is introducing eager loading. You have to be very careful when you develop the functions in the repository so that this concern can be communicated by service or business layer calling the function (Like you did with paging). Or you end up with a nice architecture but the performance suffers a lot. When using multiple data contexts you also have to be very careful not to introduce cross updates and logic that fails optimistic concurrency if wrapped in one transaction.
Great explanation of the Repository Pattern w/UOW Mosh! Your awesome presentation along with in-depth analysis of The Repository Pattern lays to rest the argument against using both TRP and Entity Framework that I have seen over the years from other camps of thought. Thnx!
Thank you so much! I'm still a newbie when it comes to developing applications on my own and due my lack of experience I've searched for a long time and read one blog post after another. In the end I was so confused about the fact, when to use what and where to write down this sh*t :) Your Video sorted out a lot questions. Keep going with your great work. Greetings from Germany :) (Please ignore my bad english)
Great video, but unfortunately the arguments were not convincing enough for me. Some reasons: - How often do you see enterprise projects switching ORMs? Also, if using Dependency Injection, you only need to refactor the layer that depends on EF, same as in your case were you would need to refactor the repository implementations. - Each ORM is different and these differences mean this repository pattern can be a leaky abstraction. For example, calling ToList() on a collection is totally unpredictable in terms of lazy/eager loading depending on a) the ORM and b) the repository implementation. - You can still extend the DbSets to have methods for common queries, same as with your repositories.
The solution architect at my firm (a great friend of mine) just defended returning IQueryable and having Modify methods in Repositories today, his argument was: it can be done and it makes it so convenient, heated debate.
I am a big fan of this solution. One small observation. Currently, it looks like many different UnitOfWork classes will need to be created to handle different types of transactions (Even if you wanted to save an simple object). However, I might not always want to create a custom class for one adhoc transaction. What if I just want a simple UnitOfWork so that I can add repositories at will. In this case you COULD get away with only one UnitOfWork implementation by creating a UnitOfWork class that doesn't have any repositories. It just allows the caller to execute the "Complete()" method. The context would already be established so passing it to the repositories would still affect change. So something like the following could be in your Program.cs: static void Main(string[] args) { var context = new PlutoContext(); using (var unitOfWork = new UnitOfWork(context)) { var courses = new CourseRepository(context); var authors = new AuthorRepository(context); // Example1 var course = courses.Get(1); // Example2 var courses = courses.GetCoursesWithAuthors(1, 4); // Example3 var author = authors.GetAuthorWithCourses(1); courses.RemoveRange(author.Courses); authors.Remove(author); unitOfWork.Complete(); } } This effectively would allow you to save changes even if you only have one repository and didn't want to create a new UnitOfWork to handle that transaction. Alternatively, you could add as many repositories and contexts as you wish, just call "SaveChanges" on all contexts when Complete is called. Hope that is not too confusing.
Great tutorial, however there's one aspect which puzzled me a bit, namely the Find method which takes a predicate as parameter. Don't you consider this as a potential risk for leaking abstraction into layers depending on the repository. There are three potential problems I can see. Firstly, not every Expression can be interpreted by EF. Secondly, there's no guarantee that a predicate which works with EF is going to work with a different data access library (let's take OData as an example). Last but not least, if somebody is working in TDD style it might get a false sense of security by mocking out the Find method (all unit tests will pass but once the code gets executed against the real repository, the implementation will break).
+Simon Farrugia you would create your own repo Find method meaning that you use the parameter house you want. You can even create your own find arguments class if you don't want to use an expression
This. Apart from the Expression-Type being in the bcl, this is a leaky abstraction of EF. No way of implementing this for ADO or Dapper. It's interesting because he mentions Dapper in the beginning and then writes an interface which is nearly impossible to implement with a lot of ORM.
Repository in UOW is an anti pattern. And using the repository to get persistence model as well . I recomend for all of you lazy busters chek definition of Repository pattern and consider what mean "for accessing domain objects.". Persistence models of ORM is not a domain object this part of infrastructure that represent table in DB. He made some sort of wrap on ORM wich is not necessary if you'r using good orm like NHibernate.
You said, you will show how to use UoW in WPF/MVVM pattern. I'm really waiting for this one. I'm not sure what's the right way, should we inject UoW initialized with the same Context into every ViewModel?
Really great video Mosh! I just brought your Udemy course for Entity Framework - love your teaching style man, very clear and well explained - this is the best explanation I have seen for the Repository pattern, hence my decision to buy the course. Cheers!
+Programming with Mosh holy guacamole! I didn't see that, I guess TH-cam is planning tricks on me lately. I really mean it, there's no subscriber count on your channel :P sorry about that
So, from architectural side it's one of the best implementation i've seen, despite some flaws: 1) exposing DbContext from a repository is almost the same as exposing save method 2) unit of work lacks transactions. while EF DbContext does not do extra roundtrips and changes to the database until save is called, NHibernate does. But even with EF it's possible to execute custom SQL that would alter the DB and since with published DB context on the repository it's possible to do this, our unit of work becomes no unit of work in that case! 3) in this case also not the repository who's acting like an in-memory collection, but the db context, and also repository, and also the repository itself does not expose save (which is a wise decision in this architecture) - so it's not a repository pattern according to definition, but yeah, it does the isolation from the db code. 4) even if injecting just X repos into unit of work, due to the ORM and the traversible object model all DbSets (so all repos) will be accessible (so theres no real repo boundary) The querying can be done with query classes (per entity or even per use-case). The one thing I like with this repo patter is, that when it's applied correctly, it can serve as an abstraction for more complex EF logic - like removing orphaned children which EF can't handle via mapping).
Please don't cherry pick. Even if you use interface, you should take care on what you expose in your implementation. Simply there's no need for the context you use inside a repo to be public (th-cam.com/video/rtXpYpZdOzM/w-d-xo.html). Furthermore: - In real scenarios you might need a mass update - custom SQL. In that case your unit of work (without transactions) might not do what it's intended. - Also your repositories do expose orm mapped entities, so they do not have real boundaries (so you did it right to put them into an unit). this part of your concept is really a good one. - Interfaces are really cool, but I assume you won't change the persistence layer and if you used the word domain, you should know that domain logic can be tested (even more easily) without repositories. So it's premature to introduce them. I still like this solution. But... I'd not use repos for: - forwarding ORM's CRUD methods - and neither for querying (for it we can use query classes, actually they are your repos without the CRUD stuff, but each query could be a separate query class, depends what complex search logix you build around it) For those, who thinks this is really an overkill (don't misunderstood me, I did similar architectures not a whole decade ago)...here's a simpler solution. 1) use query classes instead of repos 2) drop interfaces until you really need them 3) instead of coding unit of work use TransactionScope! the only thing to take care of is to create some transaction scope builder, where you can set your default isolation level (not serializable)... since you rarely need to manage 2 sets of changes inside a given thread, TransactionScope will suit most use-cases...
Very nice video, thanks! Two things which bother me 1.) why to you but public virtual DbSet Authors { get; set; } in the PlutoContext? It would be cleaner to but it in Repository as protected DbSet DbSet { get; set; } The advantage is that you don't have to change a existing class when you add a new Repository. And if you say Repository should be independent of the ORM Framework, thats not true, because DbContext ist already in it. 2.) If you add a repository you allways have to change the UnitOfWork class. So if you extend your application with new functionality you have to touch existing working code.
+Harald Schaffernak Another problem if the PlutoContext has a attributes for each possible DbSet e.g. DbSet Courses; you can access in eg. UserRepository PlutoContext.Courses.Whatever().
+Programming with Mosh Thanks for the answer. My suggestion is to put "DbSet dbSet;" in the Repository class, advantage: - You don't need to add the property "public PlutoContext PlutoContext" in each concrete Repository class (e.g. CourseRepository) - You don't need to add a DbSet property for each DAO type in the PlutoContext.cs. (e.g. public virtual DbSet Courses { get; set; }) - Most important, it is not possible to access e.g. the "DbSet Courses" from the AuthorRepository. Example: public class Repository : IRepository where TEntity : class { protected DbSet DbSet; public Repository(DbContext context) { DbSet = Context.Set(); } ... } public class CourseRepository : Repository, ICourseRepository { ... public IEnumerable GetCoursesWithAuthors(int pageIndex, int pageSize = 10) { return DbSet .Include(c => c.Author) .OrderBy(c => c.Name) .Skip((pageIndex - 1) * pageSize) .Take(pageSize) .ToList(); } ... }
Just found this. My main problem is your unit of work could get huge depending on how big the app is. Sure, you could argue, that we should be building Microservices these days. But, I think monolithic apps are still pretty popular and work well for the majority of software out there that doesn't have to scale to thousands of requests a second. I suggest using the repository, or perhaps call them Query classes and use dbContext as the unit of work. You can inject the DbContext into the Query/Repository and also us it as the unit of work. At least, this is my approach. var db = new ApplicationContext(); var customerRepo = new CustomerRepo(db); var authorsRepo = new AuthorsRepo(db); // get stuff // Change stuff db.SaveChanges(); You can inject the Repos along with the context into your MVC action as well. Your DI if configured correctly will give the controller the same context (UoW) that it gives the repositories. public void MyController(ApplicationContext context, CustomerRepostory customers) public IActionResult Edit(CustomerViewModel customerView) { var customer = customers.Get(customerView.id); // update with left right or automapper customer.Name = customerView.Name; // etc context.SaveChanges(); return View("Index"); //or whatever } Repos could/should be replaced by Query objects. So you have the benefit of the query in a single place without the overhead of a repository. Here's some great posts about this by Jimmy Bogard. www.google.com/search?q=jimmy+bogard+repository+entity+framework&rlz=1C1GCEB_enUS841US841&oq=jimmy+bogard+repository+entity+framework&aqs=chrome..69i57.9637j0j7&sourceid=chrome&ie=UTF-8 lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/
6:55 If you want to minimize duplicate code. you should not create a repository but instead a service class. Still EF is a bundle of UoW and Repository pattern. It doesn't look like they implemented it. They implemented it. 8:10 Again if you create a Service Class it's still is decoupled and you can change your ORM also this time you have much less code to refactor. Because there is just 1 service instead of couple repository classes for each dbset Summary: If you dig deeper into to real reason why (C#/ Java) developers like to build repositories. It's because they just like to create alias methods with a limited parameter set. They love to box stuff and destroy flexibility. This is great if you tend to not update your code for the rest of your life but horrible when it"s a continuous project
I have a Services _project_ (not class) and the repository pattern is still useful to me. I don't want my services to know, or care, how and where the data is persisted. I disagree that with this implementation there will be more code to refactor. There won't.
In my opinion, this implementation of UoW pattern is violating the following SOLID principles: 1. It is violating Open/Closed Principle, as it is not extendable... also if we add a new repository, we need to modify the UoW class to include the new Repository. 2. It is violating Interface-Segregation Principle. ISP states that clients should not be forced to implement interfaces they don't use. This UoW contains an implementation of all the repositories... but then a consuming client does not need all these implementation, the client would probably just need one of them. 3. It is violating Single Responsibility Principle, as the UoW is responsible for so many repositories. ----------------------------------------------------------------- Also the assumption that we don't need any Update() method in a repository is simply false, in fact DbContext has an Update() method in EF Core. This video is overlooking the complexities involved in a disconnected environment. ----------------------------------------------------------------- If you refer to MS documentation: docs.microsoft.com/en-us/dotnet/api/system.data.entity.dbcontext?redirectedfrom=MSDN&view=entity-framework-6.2.0 "DbContext represents a combination of the Unit-Of-Work and Repository patterns and enables you to query a database and group together changes that will then be written back to the store as a unit." So according to MS, DbContext is already implementing the UoW pattern... what we are doing here is wrapping the built-in UoW inside our own UoW... this does not make a lot of sense.
I have a hard time thinking of a scenario where abstracting EF is actually worth the effort. The arguments in the video assume that persistence frameworks keep coming at the same speed as they did previously but tbh EF and the NET/Core framework are so tightly coupled that you'd just as soon change the entire language or development environment. Linq2sql and nhibernate were always stopgap solutions, EF is different.
Yes @Hooman we don't want to disappoint Uncle bob by breaking these SOLID principles. Moreover, I am curious what project structure & wrapper you use while using EF as persistence layer (Hope you are not instantiating dbcontext directly from your controller) and avoid tight coupling between DAL/EF project and presentation project (asp.net MVC controllers)
@@subashp3226 simply using commands & queries (+automapper for that nice ProjectTo aka select projection) (aka CQ(R)S) As each repository method reflects a query object in fact and a collection of updates and more are encapsulated in a command object, which can call savechanges then for a complete nice set of business logic. Wish to use dapper or any other, feel free to change, or feel free to mix where needed in any command and/or query. That said, EFCore nowawayds leave you with enough options to break out and write SQL youself when needed Or else, use dapper with commands/queries + automapper where needed or in the entire project No I don't need a Unit of Work pattern. Simple cqs is enough for me, and I can test it, as well as make it ready for future scalability.
I think you are thinking about this wrong, or you are right and I am confused. Here is how I see it. There is an IUnitOfWork interface because you would create new concrete UnitOfWork classes depending on the "unit of work" you want to make transactional. So for example, if you are working with Orders, you might need to use the OrderRepository and CatalogRepository. In that case you would create an CustomerOrderUnitOfWork class that has OrderRepository and CatalogRepository as it's properties. So you would need multiple concrete UnitOfWork implementations to support your various transactional queries.
Hello Mosh I really like your style of teaching and you make it really easy to learn, I am trying to learn Domain Driven Design but I cant find any tutorial created by you, can you please do a DDD tutorial for us as well
Great presentation, and a joy to apply. One question though. Is there a clean way to support explicit loading in our unit of work? Normally this is done through the Entry API of the DbContext, but the DbContext is hidden now. One could expose Entry on the unit of work, but this would allow the user to write queries outside the unit of work. To be honest, it's not very hard to remember to use it only for explicit loading and not queries, but I was wondering if there is a way to ensure it. Thanks!
It seems like this works well when your ORM directly works with your domain entities. If you need to separate the two (e.g. ORM limitations force bad practices on domain), then it all breaks down, starting with the base Repository. Still a good intro, and good to not expose IQueryable.
Thank you! This is the best introduction to UoW IMO. I have a few things to change though, I hope you let me know your thoughts: - GetAll is not desirable to all my entities, some if not most are large datasets and I dont want to expose that. I'll remove it. - Not all my keys are int so I'll remove Get(int id) or change it with (object[] keyValues). - Find with predicate is not desirable either, if I'm using dapper to one of my repo, I don't want to be querying the Expression to get the parameters. - I'm also not into Remove where the parameter is an entity. I will have to query the item first or instantiate an entity and assign a key to it just to delete an item. - Also, I will rename Repository class to DbContextRepository and put it under something like Repository.EntityFramework namespace since it is tied to EF.
In your last two modifications I think you miss the point. The Remove method that takes an entity is to be used in cases where you _already have_ the entity loaded for whatever reason. Also, doesn't renaming the repository class and putting it into a namespace that references EF go against the idea of this being a _generic_ collection of objects so that you can modify it or parts of it to use another ORM without making _any_ changes to your application code?
It's amazing that what Mosh taught here in 2015 still holds true in the first day of 2020. Cheers!
Mosh is a legend
True that
How is that the case ur queues will have link and lambada it would be harder
2021 now and still going strong
is this because of the undying nature of pattern?
You say that your CourseRepository knows nothing about EntityFramework, however, it is strongly coupled to EntityFramework, because it's base class, Repository injects a DbContext, which is EntityFramework specific. If you remove the `System.Data.Entity` reference, and swap it with another ORM, the whole things breaks. So it's wholly dependent on EF, from the generic base class, upwards. You should really name your generic repo as `EntityFrameworkRepository`, to show that it is dependent on EF. But this will still mean the app breaks when you swap ORMs. It would just make it more clear, as to why.
Mosh, I don't know if you still read this but I wanted to say THANK YOU for taking the time to go over the arguments that EF already implements the repo pattern, etc etc, and demonstrate that this is not exactly the case. This entire debate had me so confused for quite a while, and you did a _great_ job putting it to rest (for me, at least). The demonstration is also nicely done. Thanks, really.
I have done repository before and I am new to unit of work. My repositories have save and delete methods. The way you explain unit of work here has helped me a great deal I will be implementing this pattern much more often.
Right? That was so helpful
I've listened to many Mosh tutorials over the years, and this one is still the most impressive to me... he says the same things as many other videos, but the cadence along with the presentation queues simply flow better here. It's why I've come back to listen to it repeatedly... it's also superior in quality vs an average college lecture.
Coulnd't agree more
Excellent. Probably the clearest, most concise, and easiest to grok tutorial on the Repository Pattern I've ever watched.
Find method in IRepository is breaking the rules of having the query written only once. A developer can inject any expression in it duplicating queries in different repository clients.
I'd remove it from the interface and allow only named query methods. Specification pattern might be an alternative option but that in the end kind of boils down to the same thing.
I was searching 2 days for guide like that and everything was a trash, lessons without understanding the base... and only now youtube proposed me this video and it's perfect!!! My huge respect to author !!! Like and subscription :)
The number one ! I have about 4 Mosh courses on Udemy. They all help me today.
With that I gained better job opportunities. Thank you!
Nice video. I tend to find for smaller projects Entity Framework is just fine for a repository and unit of work pattern as there is less if no duplication of queries. I have used your pattern before and found it to be too much for small projects. My only advice is: Do what is best for your particular project. There is no one size fits all solution. The solution posted in this video is great for a larger application.
"simplicity is the ultimate sophistication" and your training also simple & Clear about a complex pattern.
I agree with you Mosh. Repository Pattern has become a mystery to me ever since I tried to explore it and for the most part articles from different developers have different implementations of Repository Pattern in which it is hard to determine which is actually the right one.
I was about to not use repo pattern on my project because of other videos saying it was redundant, but your explanation made so much sense and was really easy to understand, thanks for taking the time to make this video.
Your "IRepository" has "Find" method with "Exspression predicate" parameter. How are you going to implement it with stored procedures?
Abolutely brilliant! This finally made everything 'click' on using the Repository pattern with EF6. I'd avoided it because it seemed like far too much work for too little benefit vs. using DbContext directly,
The way you explain things is so uncomplicated you almost make it seem like this stuff is easy. Thanks a load mate. Your tutorials are excellent.
Saw dozens of tuts but literally this was awesome simple and focused, I feel confidence now. Thanks a lot!
Hi Mosh, Thanks for the excellent presentation. I have gone through many of the comments. Here are my consolidated queries.
1) Find method which takes a predicate as the parameter. Don't you consider this as a potential risk for leaking abstraction into layers depending on the repository
a) not every Expression can be interpreted by EF
b) there's no guarantee that a predicate which works with EF is going to work with a different data access library (let's take OData as an example)
So the only solution here is to write Find method in each repository as per the requirement?
2) Since many of the RealWorld applications contain more than 100 Repository classes. It's now important to learn about bounded contexts in Domain Driven development so that we can architect a project by splitting it into different domain projects and use related bounded contexts. I have gone through several articles on this topic. But could you please prepare and post a video on it by covering all the concepts like (MVC, EF, DDD, BC, DI....)
Because I think you are the best person who can explain the things in a clear manner. :)
Thanks,
Vinay
These is the best tutorial i have found that explains a concept i have been trying to grasp for the last 2 weeks. Very precise and explains everything in details.
Its a really amazing and simple explanation. Thanks Mosh. I regret taking a course at Naresh IT, Hydrabad. They wasted my time and money. Thanks again Mosh.
You're such an amazing instructor who can simplify the information in perfect way and make the listener understand well .. thanks Mosh and I hope you to share more videos and courses
IMO, the “collection-like interface” is the least important and most out-dated portion of the repository pattern. The most important part of the pattern is to isolate the rest of your application from the persistence logic. You typically don’t want to reuse repository methods. Since your business logic shouldn’t be in the repository, you don’t want multiple code paths reusing a repo method like SaveArticle(Article article). Instead reuse the same service method that calls the repo so the same business logic is enforced. Too many coders try to get cute/clever with generic repositories, exposing IQueryable, etc. EF performs poorly enough all by itself. It doesn’t need help being slower by the n+1 problems created by not writing custom linq queries that specify the include. Of course it always depends on the specific constraints of the application. Thank you for your great videos.
Indeed! +1
The best video I've seen for repository pattern - clean and simple.
I think you should have touched a bit on ".AsNoTracking()" and perhaps also .Attach(), EntityState.Modified and EntityState.Detached, since e.g. retrieving all courses without intent to change anything, is probably the most common use case. Then you can just attach the specific course when you actually want to change it, i.e. have Entity Framework track it for you. If all retrieved objects are tracked all the time, it's a huge impact on performance.
When I do greenfield development I always do Controller -> Service(es) -> Repositories -> EF/DbContext (and/or MongoDb). This has been a very good pattern for me/us, as it's clean and very effective. Having a repository present two different database technologies as a single source, gives a lot of freedom to concentrate on the business logic and not the database implementation
This is, truly, the best resource on the subject that I've seen. Thank you
Good video.
Some things:
1) I think that the GetAll method is not so generic to be part of the interface and can be a little dangerous. Here where I work, many times people use the GetAll and then filter the results in memory (even when the original data has millions of rows).
2) I think that the Find method must hava a call to ToList (or AsEnumerable) before return the results, so an user can´t cast it back to IQueryable.
Best explanation I've yet to see of the repository pattern.
11:10 - 11:15: I personally think that your work is not wasted. When you have full separation of concerns you can re-use the logic very quickly in other apps even if their purpose is different.
BTW, thanks a bunch for the video.
This channel is gold mine for C# Beginners and Aspirants.
You should watch it all (fantastic video) but if you're in a rush skip to 12:00 for the implementation bit! Cheers
Best explanation I have heard to date on the repository pattern. I am much closer to understanding it now
You say there is no need to update in the repository pattern. But, actually you do need to update records. Thanks for leaving out that extremely important piece of information!!
If you don't want to over complicate things with the unit of work, you can have a simple update in your repository like this:
public MyEntity Update(int id, MyEntity newEntityValues)
{
using (var context = new MyDbContext())
{
var entity = context.MyEntities.Find(id);
context.Entry(entity).CurrentValues.SetValues(newEntityValues);
context.SaveChanges();
return entity;
}
}
The video title says "Repository Pattern with C# and Entity Framework". Yet, you are adding complexity so that you do not have to use EF in the future. Not necessary for the first implementation of your repository pattern. You can still use testing frameworks to test your methods
Best video I've seen on this topic, and its easily understandable from what you mention and you give course materials! Looking forward to working through your Pluralsight courses.
I should advice from experience on two distinct projects which followed this idea of encapsulating EF within our own Repository + UOW: Don't do it!
EF already does it and you could use Specification patterns to easily overcome the problem of repeating querying logic.
Also, your entire application DOES NOT need to use only one ORM. It's fine to use EF for simple/non-performant areas/contexts and use something else like PetaPoco for areas where you need performance, etc.
Another idea if you still want to have a class named Repository: Just make it a simple class where you inject the DbContext. It would sort of work as a decorator over the DbContext. On the two projects I've worked we followed this (IMO) contrived inheritance of BaseRepositoryClass + BaseRepositoryInterface + ActualRepositoryInterface + ActualBaseRepositoryClass inheriting from all of that: I have deeply regretted doing so.
It is like CQRS when folks hear about: Let's implement it on all our system. No! Only do it for the relevant areas/domains/bounded contexts of your code.
the application in the video is just for a demonstration!
What if id is type of Guid, then your generic repository will not work. Here is iEntity comes to play. Your domains should inherit from iEntity, so you can query based on id
I get it! And this is the first time it has really been made clear to me! I have been playing with the repository pattern for a few years now and have used it in several projects, with a degree of success but it always get messy when the project had to do tricky things or when the project got bigger. I would not end up maintaining the DRYness that I like. I could see the benefit but was still only really successful with it in small projects that I saved through calls in the interface as well. The way you use the UnitOfWork pattern is really cool!
I'm also taking your Angular2 course on Udemy and you are great there as well!
Thanks so much for your clarity!
Irv
Almost 2 years and you still made a lot of sense.
thanks so much. You are the best
This is by far the best explanation on repositories that I've seen online so far. When is your course on Pluralsight coming out?
Just wow, you completely blew me away with your well-cut explanations. Excellent job Mosh.
where've you been man i was searching for you thought :p
as you said in the begging i've read a lot about unit of work and repository but i didn't get it clean and with this video you've explain it well thank you very much. it helps a lot, waiting for more from you.
One of the finest explanation of repository pattern with c# and EF. Thanks to you, I really appreciate the quality and content of the video. After reading many questions in the discussions section, I believe someone needs to address - how to overcome the challenges by Botond related to Find method, as well as, what should be the approach when an ORM gets changed? For example, later on, if we want to use Nhibernate instead of EF then what would be the possible changes
Mosh! Thank you so much for this video. I stumbled upon it when designing the architecture of a website I'm working on.
I'd read so many conflicting views on why/not to use repositories with Entity Framework - most of them against using repositories for the same reason you said you've come across a lot, too.
You've explained very clearly to me how it is beneficial, and I also picked up some tips on how to create some Generic repositories in future.
Well worth a watch, and I'll be coming back in future to view more of your videos!
Thanks!
Amazing Explanation. Gained a lot of precise information in a very short span. That's what I love most about your videos.
One of the disadvantages of using the repository pattern is introducing eager loading. You have to be very careful when you develop the functions in the repository so that this concern can be communicated by service or business layer calling the function (Like you did with paging). Or you end up with a nice architecture but the performance suffers a lot.
When using multiple data contexts you also have to be very careful not to introduce cross updates and logic that fails optimistic concurrency if wrapped in one transaction.
Great explanation of the Repository Pattern w/UOW Mosh! Your awesome presentation along with in-depth analysis of The Repository Pattern lays to rest the argument against using both TRP and Entity Framework that I have seen over the years from other camps of thought. Thnx!
Excellent explanation. Clearly understand about the Repository & Generic Repository pattern. Thanks alot
Thank you Mosh, Thank you for a very comprehensive demonstrations of repository pattern, I enjoyed it for sure
Very well presentation of Repository! Greetings from Bulgaria!
Thank you so much for very comprehensive demonstration of Repository pattern. Well explained
Thank you so much! I'm still a newbie when it comes to developing applications on my own and due my lack of experience
I've searched for a long time and read one blog post after another. In the end I was so confused about the fact, when to use what and where to write down this sh*t :) Your Video sorted out a lot questions. Keep going with your great work.
Greetings from Germany :)
(Please ignore my bad english)
The best explanation on Repository Pattern
My favorite video about repository pattern + unit of work video
Great video, but unfortunately the arguments were not convincing enough for me. Some reasons:
- How often do you see enterprise projects switching ORMs? Also, if using Dependency Injection, you only need to refactor the layer that depends on EF, same as in your case were you would need to refactor the repository implementations.
- Each ORM is different and these differences mean this repository pattern can be a leaky abstraction. For example, calling ToList() on a collection is totally unpredictable in terms of lazy/eager loading depending on a) the ORM and b) the repository implementation.
- You can still extend the DbSets to have methods for common queries, same as with your repositories.
I know that you are the best guy in this town (youtube tutorial town).
Great!
It's the best video/article/lesson I have found on the internet. Thank you :)
Extremely well explained the theory is key to implementing any concept and you do well to explain the same.
just million likes!!! thank you so much!!! many many thanks!!!
The solution architect at my firm (a great friend of mine) just defended returning IQueryable and having Modify methods in Repositories today, his argument was: it can be done and it makes it so convenient, heated debate.
man..... you are just amazing. often your way of thinking reminds me how exactly I think...... keep up the good work.
I am a big fan of this solution. One small observation. Currently, it looks like many different UnitOfWork classes will need to be created to handle different types of transactions (Even if you wanted to save an simple object). However, I might not always want to create a custom class for one adhoc transaction. What if I just want a simple UnitOfWork so that I can add repositories at will. In this case you COULD get away with only one UnitOfWork implementation by creating a UnitOfWork class that doesn't have any repositories. It just allows the caller to execute the "Complete()" method. The context would already be established so passing it to the repositories would still affect change. So something like the following could be in your Program.cs:
static void Main(string[] args)
{
var context = new PlutoContext();
using (var unitOfWork = new UnitOfWork(context))
{
var courses = new CourseRepository(context);
var authors = new AuthorRepository(context);
// Example1
var course = courses.Get(1);
// Example2
var courses = courses.GetCoursesWithAuthors(1, 4);
// Example3
var author = authors.GetAuthorWithCourses(1);
courses.RemoveRange(author.Courses);
authors.Remove(author);
unitOfWork.Complete();
}
}
This effectively would allow you to save changes even if you only have one repository and didn't want to create a new UnitOfWork to handle that transaction. Alternatively, you could add as many repositories and contexts as you wish, just call "SaveChanges" on all contexts when Complete is called. Hope that is not too confusing.
I just migrated from exactly that implementation to the one in this video as this one makes much more sense and actually reduces work.
Great tutorial, however there's one aspect which puzzled me a bit, namely the Find method which takes a predicate as parameter. Don't you consider this as a potential risk for leaking abstraction into layers depending on the repository. There are three potential problems I can see. Firstly, not every Expression can be interpreted by EF. Secondly, there's no guarantee that a predicate which works with EF is going to work with a different data access library (let's take OData as an example). Last but not least, if somebody is working in TDD style it might get a false sense of security by mocking out the Find method (all unit tests will pass but once the code gets executed against the real repository, the implementation will break).
Very good point. Can anybody answer this please.
+Simon Farrugia you would create your own repo Find method meaning that you use the parameter house you want. You can even create your own find arguments class if you don't want to use an expression
This. Apart from the Expression-Type being in the bcl, this is a leaky abstraction of EF. No way of implementing this for ADO or Dapper. It's interesting because he mentions Dapper in the beginning and then writes an interface which is nearly impossible to implement with a lot of ORM.
Repository in UOW is an anti pattern. And using the repository to get persistence model as well . I recomend for all of you lazy busters chek definition of Repository pattern and consider what mean "for accessing domain objects.". Persistence models of ORM is not a domain object this part of infrastructure that represent table in DB.
He made some sort of wrap on ORM wich is not necessary if you'r using good orm like NHibernate.
Yes, truly abstracting away EF is difficult and, in most cases, pointless (YAGNI).
You said, you will show how to use UoW in WPF/MVVM pattern. I'm really waiting for this one. I'm not sure what's the right way, should we inject UoW initialized with the same Context into every ViewModel?
+1 to that! I'm eagerly awaiting a video on implementing UoW in ASP.NET, as Mosh mentioned in the video.
Please, make a video about using UoW in ASP.NET MVC with IoC/DI...
I've been to the courses, I have a question, if I have hundreds of repositories, is it ok to initialize them all in Unit of work constructor?
You can use lazy intilization, and only initilize if someone needs it
yeah! I encountered exactly the same issue...I abandoned the unit of work, and used the repos...
Brilliant and easy to learn presentation, Mosh. Hats off to you. Thanks a ton and please keep it up 🙏👍
Excellent, I was struggling to understand repository realtime use...Now I know it.....Thanks Buddy.....
Hi Mosh, do you have any video on Factory vs Abstract Factory scenarios??
Really great video Mosh! I just brought your Udemy course for Entity Framework - love your teaching style man, very clear and well explained - this is the best explanation I have seen for the Repository pattern, hence my decision to buy the course. Cheers!
very clear explanation and clear diction of voice, you just earned your first subscriber ;) keep 'em coming 'mate!
+Programming with Mosh holy guacamole! I didn't see that, I guess TH-cam is planning tricks on me lately. I really mean it, there's no subscriber count on your channel :P sorry about that
Excellent video ! very clair and concise explanations, thanks a lot !!
So, from architectural side it's one of the best implementation i've seen, despite some flaws:
1) exposing DbContext from a repository is almost the same as exposing save method
2) unit of work lacks transactions. while EF DbContext does not do extra roundtrips and changes to the database until save is called, NHibernate does. But even with EF it's possible to execute custom SQL that would alter the DB and since with published DB context on the repository it's possible to do this, our unit of work becomes no unit of work in that case!
3) in this case also not the repository who's acting like an in-memory collection, but the db context, and also repository, and also the repository itself does not expose save (which is a wise decision in this architecture) - so it's not a repository pattern according to definition, but yeah, it does the isolation from the db code.
4) even if injecting just X repos into unit of work, due to the ORM and the traversible object model all DbSets (so all repos) will be accessible (so theres no real repo boundary)
The querying can be done with query classes (per entity or even per use-case). The one thing I like with this repo patter is, that when it's applied correctly, it can serve as an abstraction for more complex EF logic - like removing orphaned children which EF can't handle via mapping).
Please don't cherry pick. Even if you use interface, you should take care on what you expose in your implementation. Simply there's no need for the context you use inside a repo to be public (th-cam.com/video/rtXpYpZdOzM/w-d-xo.html).
Furthermore:
- In real scenarios you might need a mass update - custom SQL. In that case your unit of work (without transactions) might not do what it's intended.
- Also your repositories do expose orm mapped entities, so they do not have real boundaries (so you did it right to put them into an unit). this part of your concept is really a good one.
- Interfaces are really cool, but I assume you won't change the persistence layer and if you used the word domain, you should know that domain logic can be tested (even more easily) without repositories. So it's premature to introduce them.
I still like this solution. But... I'd not use repos for:
- forwarding ORM's CRUD methods
- and neither for querying (for it we can use query classes, actually they are your repos without the CRUD stuff, but each query could be a separate query class, depends what complex search logix you build around it)
For those, who thinks this is really an overkill (don't misunderstood me, I did similar architectures not a whole decade ago)...here's a simpler solution.
1) use query classes instead of repos
2) drop interfaces until you really need them
3) instead of coding unit of work use TransactionScope! the only thing to take care of is to create some transaction scope builder, where you can set your default isolation level (not serializable)... since you rarely need to manage 2 sets of changes inside a given thread, TransactionScope will suit most use-cases...
Why has this only got 62 up-votes? This is a wonderfully clear tutorial. Thanks for posting it.
+dibley1973 - What is more how the hell has it got two down-votes? What numpty down voted it?
Very helpful. Great clarity in content and beautiful slides.
Thank you Mosh. Outstanding presentation!!
Wonderful teaching - so useful and elegant! Thanks as always Mosh!
Excellent Tutorial. Thanks Mosh.
Very nice video, thanks! Two things which bother me 1.) why to you but
public virtual DbSet Authors { get; set; }
in the PlutoContext? It would be cleaner to but it in Repository as
protected DbSet DbSet { get; set; }
The advantage is that you don't have to change a existing class when you add a new Repository. And if you say Repository should be independent of the ORM Framework, thats not true, because DbContext ist already in it.
2.) If you add a repository you allways have to change the UnitOfWork class. So if you extend your application with new functionality you have to touch existing working code.
+Harald Schaffernak Another problem if the PlutoContext has a attributes for each possible DbSet e.g. DbSet Courses; you can access in eg. UserRepository PlutoContext.Courses.Whatever().
+Programming with Mosh Thanks for the answer. My suggestion is to put "DbSet dbSet;" in the Repository class, advantage:
- You don't need to add the property "public PlutoContext PlutoContext" in each concrete Repository class (e.g. CourseRepository)
- You don't need to add a DbSet property for each DAO type in the PlutoContext.cs. (e.g. public virtual DbSet Courses { get; set; })
- Most important, it is not possible to access e.g. the "DbSet Courses" from the AuthorRepository.
Example:
public class Repository : IRepository where TEntity : class
{
protected DbSet DbSet;
public Repository(DbContext context)
{
DbSet = Context.Set();
}
...
}
public class CourseRepository : Repository, ICourseRepository
{
...
public IEnumerable GetCoursesWithAuthors(int pageIndex, int pageSize = 10)
{
return DbSet
.Include(c => c.Author)
.OrderBy(c => c.Name)
.Skip((pageIndex - 1) * pageSize)
.Take(pageSize)
.ToList();
}
...
}
+Programming with Mosh Thanks, this makes sense.
really easy to listen, easy to understand! Thanks
Excellent video to demonstrate repository and unit of work..
Thanks a lot!!
Just found this.
My main problem is your unit of work could get huge depending on how big the app is. Sure, you could argue, that we should be building Microservices these days. But, I think monolithic apps are still pretty popular and work well for the majority of software out there that doesn't have to scale to thousands of requests a second.
I suggest using the repository, or perhaps call them Query classes and use dbContext as the unit of work. You can inject the DbContext into the Query/Repository and also us it as the unit of work. At least, this is my approach.
var db = new ApplicationContext();
var customerRepo = new CustomerRepo(db);
var authorsRepo = new AuthorsRepo(db);
// get stuff
// Change stuff
db.SaveChanges();
You can inject the Repos along with the context into your MVC action as well. Your DI if configured correctly will give the controller the same context (UoW) that it gives the repositories.
public void MyController(ApplicationContext context, CustomerRepostory customers)
public IActionResult Edit(CustomerViewModel customerView)
{
var customer = customers.Get(customerView.id);
// update with left right or automapper
customer.Name = customerView.Name;
// etc
context.SaveChanges();
return View("Index"); //or whatever
}
Repos could/should be replaced by Query objects. So you have the benefit of the query in a single place without the overhead of a repository.
Here's some great posts about this by Jimmy Bogard.
www.google.com/search?q=jimmy+bogard+repository+entity+framework&rlz=1C1GCEB_enUS841US841&oq=jimmy+bogard+repository+entity+framework&aqs=chrome..69i57.9637j0j7&sourceid=chrome&ie=UTF-8
lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/
Really good explanation of Repository pattern.
6:55 If you want to minimize duplicate code. you should not create a repository but instead a service class. Still EF is a bundle of UoW and Repository pattern. It doesn't look like they implemented it. They implemented it.
8:10 Again if you create a Service Class it's still is decoupled and you can change your ORM also this time you have much less code to refactor. Because there is just 1 service instead of couple repository classes for each dbset
Summary:
If you dig deeper into to real reason why (C#/ Java) developers like to build repositories. It's because they just like to create alias methods with a limited parameter set. They love to box stuff and destroy flexibility. This is great if you tend to not update your code for the rest of your life but horrible when it"s a continuous project
I have a Services _project_ (not class) and the repository pattern is still useful to me. I don't want my services to know, or care, how and where the data is persisted.
I disagree that with this implementation there will be more code to refactor. There won't.
Great explanation...very clear cut....help me understand this pattern and how to implment it nicely...
Thanks! Great and clear. I think your Iranian. Long life you and Iran.
Fantastic video. Really sums up a lot of questions i had
Excellent presentation Mosh. You really made it simple.
Thanks Mosh! You're the real MVP!
This video is gold!
you're a superstar mosh. this really helped me a lot
Nice and clean ! I like the way you explain things ! Thanks a lot Mosh !
In my opinion, this implementation of UoW pattern is violating the following SOLID principles:
1. It is violating Open/Closed Principle, as it is not extendable... also if we add a new repository, we need to modify the UoW class to include the new Repository.
2. It is violating Interface-Segregation Principle. ISP states that clients should not be forced to implement interfaces they don't use. This UoW contains an implementation of all the repositories... but then a consuming client does not need all these implementation, the client would probably just need one of them.
3. It is violating Single Responsibility Principle, as the UoW is responsible for so many repositories.
-----------------------------------------------------------------
Also the assumption that we don't need any Update() method in a repository is simply false, in fact DbContext has an Update() method in EF Core. This video is overlooking the complexities involved in a disconnected environment.
-----------------------------------------------------------------
If you refer to MS documentation: docs.microsoft.com/en-us/dotnet/api/system.data.entity.dbcontext?redirectedfrom=MSDN&view=entity-framework-6.2.0
"DbContext represents a combination of the Unit-Of-Work and Repository patterns and enables you to query a database and group together changes that will then be written back to the store as a unit."
So according to MS, DbContext is already implementing the UoW pattern... what we are doing here is wrapping the built-in UoW inside our own UoW... this does not make a lot of sense.
I have a hard time thinking of a scenario where abstracting EF is actually worth the effort. The arguments in the video assume that persistence frameworks keep coming at the same speed as they did previously but tbh EF and the
NET/Core framework are so tightly coupled that you'd just as soon change the entire language or development environment. Linq2sql and nhibernate were always stopgap solutions, EF is different.
Yes @Hooman we don't want to disappoint Uncle bob by breaking these SOLID principles. Moreover, I am curious what project structure & wrapper you use while using EF as persistence layer (Hope you are not instantiating dbcontext directly from your controller) and avoid tight coupling between DAL/EF project and presentation project (asp.net MVC controllers)
@@subashp3226 simply using commands & queries (+automapper for that nice ProjectTo aka select projection) (aka CQ(R)S)
As each repository method reflects a query object in fact
and a collection of updates and more are encapsulated in a command object, which can call savechanges then for a complete nice set of business logic.
Wish to use dapper or any other, feel free to change, or feel free to mix where needed in any command and/or query.
That said, EFCore nowawayds leave you with enough options to break out and write SQL youself when needed
Or else, use dapper with commands/queries + automapper where needed or in the entire project
No I don't need a Unit of Work pattern.
Simple cqs is enough for me, and I can test it, as well as make it ready for future scalability.
Hi Mosh,
The video is crisp and clear.
The above comment that you're breaking SOLID, I'm not sure about. Can you please shed some light on it.
I think you are thinking about this wrong, or you are right and I am confused. Here is how I see it. There is an IUnitOfWork interface because you would create new concrete UnitOfWork classes depending on the "unit of work" you want to make transactional. So for example, if you are working with Orders, you might need to use the OrderRepository and CatalogRepository. In that case you would create an CustomerOrderUnitOfWork class that has OrderRepository and CatalogRepository as it's properties. So you would need multiple concrete UnitOfWork implementations to support your various transactional queries.
Hello Mosh I really like your style of teaching and you make it really easy to learn, I am trying to learn Domain Driven Design but I cant find any tutorial created by you, can you please do a DDD tutorial for us as well
U are awesome... man.. You just cleared all my doubts regarding these...
Very good tutorial and explanation.
Thank you
Thanks man, you are my mentor.
Its funny that the advertisement "Get the full course with a discount." get pops up when mosh says "And this is where things get interesting." 5:00
Great presentation, and a joy to apply. One question though. Is there a clean way to support explicit loading in our unit of work? Normally this is done through the Entry API of the DbContext, but the DbContext is hidden now. One could expose Entry on the unit of work, but this would allow the user to write queries outside the unit of work. To be honest, it's not very hard to remember to use it only for explicit loading and not queries, but I was wondering if there is a way to ensure it. Thanks!
Loving your tutorials, very clear and easy to follow Thanks!!
It seems like this works well when your ORM directly works with your domain entities. If you need to separate the two (e.g. ORM limitations force bad practices on domain), then it all breaks down, starting with the base Repository. Still a good intro, and good to not expose IQueryable.
I love you moshfegh. good job.
Thank you! This is the best introduction to UoW IMO. I have a few things to change though, I hope you let me know your thoughts:
- GetAll is not desirable to all my entities, some if not most are large datasets and I dont want to expose that. I'll remove it.
- Not all my keys are int so I'll remove Get(int id) or change it with (object[] keyValues).
- Find with predicate is not desirable either, if I'm using dapper to one of my repo, I don't want to be querying the Expression to get the parameters.
- I'm also not into Remove where the parameter is an entity. I will have to query the item first or instantiate an entity and assign a key to it just to delete an item.
- Also, I will rename Repository class to DbContextRepository and put it under something like Repository.EntityFramework namespace since it is tied to EF.
Why Get(object[] keyValues) instead of Get(TId Id)?
In your last two modifications I think you miss the point. The Remove method that takes an entity is to be used in cases where you _already have_ the entity loaded for whatever reason. Also, doesn't renaming the repository class and putting it into a namespace that references EF go against the idea of this being a _generic_ collection of objects so that you can modify it or parts of it to use another ORM without making _any_ changes to your application code?