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'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.
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.
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.
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.
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 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.
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
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.
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.
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 :)
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.
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
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.
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.
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
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.
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,
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.
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.
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!
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.
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.
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
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!
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.
+Programming with Mosh holy guacamole! I didn't see that, I guess RUclips is planning tricks on me lately. I really mean it, there's no subscriber count on your channel :P sorry about that
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?
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
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
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
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!
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.
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.
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(); } ... }
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?
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.
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/
This example is great. It happens to use EF implicitly (I infer PlutoContext is a DBContext). Question: How would the repository pattern be used without EF?
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.
If you need to do GetTopSellingCourses , GetCoursesWithAuthors you can just use a CQRS implementation to have these well defined and use some kind of mediator. No need to make repositories just to do UOW , specifically if using Ef framework. If you suddenly decided to change to other framework that's different, but how many times have you switched out completely a db framework when working in an enterprise? Also with this UOW example shown, you'll end up with a huge ctor of 'UnitOfWork' with 100s of repos, because enterprises don't have 1-2 tables for sure.
![Megan Thee Stallion - Bigger In Texas [Official Video]](http://i.ytimg.com/vi/QxTkZTLWdo4/mqdefault.jpg)
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?
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'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
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.
Excellent. Probably the clearest, most concise, and easiest to grok tutorial on the Repository Pattern I've ever watched.
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
Your "IRepository" has "Find" method with "Exspression predicate" parameter. How are you going to implement it with stored procedures?
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.
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!
"simplicity is the ultimate sophistication" and your training also simple & Clear about a complex pattern.
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
Saw dozens of tuts but literally this was awesome simple and focused, I feel confidence now. Thanks a lot!
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.
This is, truly, the best resource on the subject that I've seen. Thank you
The best video I've seen for repository pattern - clean and simple.
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.
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
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.
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.
Best explanation I've yet to see of the repository pattern.
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 :)
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.
This is by far the best explanation on repositories that I've seen online so far. When is your course on Pluralsight coming out?
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
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.
Best explanation I have heard to date on the repository pattern. I am much closer to understanding it now
Just wow, you completely blew me away with your well-cut explanations. Excellent job Mosh.
This channel is gold mine for C# Beginners and Aspirants.
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.
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
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!
Great!
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,
Excellent explanation. Clearly understand about the Repository & Generic Repository pattern. Thanks alot
My favorite video about repository pattern + unit of work video
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).
Amazing Explanation. Gained a lot of precise information in a very short span. That's what I love most about your videos.
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.
The best explanation on Repository Pattern
Almost 2 years and you still made a lot of sense.
thanks so much. You are the best
Thank you so much for very comprehensive demonstration of Repository pattern. Well explained
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!
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.
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.
Thank you Mosh, Thank you for a very comprehensive demonstrations of repository pattern, I enjoyed it for sure
Excellent Tutorial. Thanks Mosh.
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
really easy to listen, easy to understand! Thanks
Thank you Mosh. Outstanding presentation!!
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!
Excellent presentation Mosh.
could you please send me the source code?
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.
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 RUclips is planning tricks on me lately. I really mean it, there's no subscriber count on your channel :P sorry about that
Very well presentation of Repository! Greetings from Bulgaria!
Excellent presentation Mosh. You really made it simple.
Extremely well explained the theory is key to implementing any concept and you do well to explain the same.
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?
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
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
It's the best video/article/lesson I have found on the internet. Thank you :)
Fantastic video. Really sums up a lot of questions i had
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
just million likes!!! thank you so much!!! many many thanks!!!
Brilliant and easy to learn presentation, Mosh. Hats off to you. Thanks a ton and please keep it up 🙏👍
This video is gold!
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!
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.
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.
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.
Great explained! Thanks
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...
Wonderful teaching - so useful and elegant! Thanks as always Mosh!
I know that you are the best guy in this town (youtube tutorial town).
Thanks man, you are my mentor.
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?
Really good explanation of Repository pattern.
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.
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
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/
Best quality! I have read lots of resources on the Internet, but your explanation is excellent.
I have one question. How I should update rows in db?
GREAT TUTORIAL !!!
Nice and clean ! I like the way you explain things ! Thanks a lot Mosh !
Wonderful explanation!
This example is great. It happens to use EF implicitly (I infer PlutoContext is a DBContext). Question: How would the repository pattern be used without EF?
Great explanation...very clear cut....help me understand this pattern and how to implment it nicely...
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??
man..... you are just amazing. often your way of thinking reminds me how exactly I think...... keep up the good work.
Very good tutorial and explanation.
Thank you
Excellent video ! very clair and concise explanations, thanks a lot !!
I love you moshfegh. good job.
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.
Thanks Mosh! You're the real MVP!
Thank you very much. I will experiment this to understand more about.
you're a superstar mosh. this really helped me a lot
Excellent video to demonstrate repository and unit of work..
Thanks a lot!!
Loving your tutorials, very clear and easy to follow Thanks!!
Very Good! Straight to point!
Very helpful. Great clarity in content and beautiful slides.
If you need to do GetTopSellingCourses , GetCoursesWithAuthors you can just use a CQRS implementation to have these well defined and use some kind of mediator. No need to make repositories just to do UOW , specifically if using Ef framework. If you suddenly decided to change to other framework that's different, but how many times have you switched out completely a db framework when working in an enterprise? Also with this UOW example shown, you'll end up with a huge ctor of 'UnitOfWork' with 100s of repos, because enterprises don't have 1-2 tables for sure.
U are awesome... man.. You just cleared all my doubts regarding these...