Repository Pattern with C# and Entity Framework, Done Right | Mosh

[@mikedqin]

It's amazing that what Mosh taught here in 2015 still holds true in the first day of 2020. Cheers!

[@kademmohammed6836]

Mosh is a legend

[@wordlifejohn1122]

True that

[@dotnetdevni]

How is that the case ur queues will have link and lambada it would be harder

[@TheDude0924]

2021 now and still going strong

[@andeslam7370]

is this because of the undying nature of pattern?

[@ApacheGamingUK]

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.

[@hardryv3719]

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.

[@Freefalling_shr]

Coulnd't agree more

[@marc2377]

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.

[@BryanJohns]

Excellent. Probably the clearest, most concise, and easiest to grok tutorial on the Repository Pattern I've ever watched.

[@Thenbafan45]

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.

[@DodaGarcia]

Right? That was so helpful

[@FabioCordeiro_RJ]

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!

[@milanimilivoj]

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.

[@mykhailo-kmet]

Your "IRepository" has "Find" method with "Exspression predicate" parameter. How are you going to implement it with stored procedures?

[@kuroki_suzume]

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 :)

[@briankarcher4418]

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.

[@jobycheriyan9740]

"simplicity is the ultimate sophistication" and your training also simple & Clear about a complex pattern.

[@SonnyRecio]

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.

[@mikebarger]

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.

[@psyaviah]

Indeed! +1

[@Pest87]

The best video I've seen for repository pattern - clean and simple.

[@HugRunner]

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.

[@david3552]

This is, truly, the best resource on the subject that I've seen. Thank you

[@CarlosAlbertoCostaBeppler]

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.

[@kingmaduma1783]

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.

[@pierrenilsson4179]

Best explanation I've yet to see of the repository pattern.

[@VinayKumar-qu1eg]

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

[@kevina4600]

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.

[@sohailarshed3427]

Saw dozens of tuts but literally this was awesome simple and focused, I feel confidence now. Thanks a lot!

[@gauravpathare208]

This channel is gold mine for C# Beginners and Aspirants.

[@Gojam12]

Best explanation I have heard to date on the repository pattern. I am much closer to understanding it now

[@matigarimanjirungi59]

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.

[@javiasilis]

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.

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

[@xhiris5844]

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,

[@ReuelRamos]

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.

[@seldah]

the application in the video is just for a demonstration!

[@ayaosama3839]

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

[@benripka6977]

You should watch it all (fantastic video) but if you're in a rush skip to 12:00 for the implementation bit! Cheers

[@RudraPratapSinghLearning]

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.

[@roylee3196]

Just wow, you completely blew me away with your well-cut explanations. Excellent job Mosh.

[@BotondBotos]

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).

[@simonfarrugia26]

Very good point. Can anybody answer this please.

[@Omego2K]

+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

[@christoph_wattever]

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.

[@joordanyt]

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.

[@michaelmarchese5865]

Yes, truly abstracting away EF is difficult and, in most cases, pointless (YAGNI).

[@mshevroja]

My favorite video about repository pattern + unit of work video

[@chrisjrocks604]

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!!

[@chrisjrocks604]

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; } }

[@chrisjrocks604]

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

[@olawoleomotosho4836]

Almost 2 years and you still made a lot of sense. thanks so much. You are the best

[@frankhaugen]

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

[@mohsinmemon3362]

Excellent explanation. Clearly understand about the Repository & Generic Repository pattern. Thanks alot

[@israilkarud9293]

The best explanation on Repository Pattern

[@khrazy5150]

This is by far the best explanation on repositories that I've seen online so far. When is your course on Pluralsight coming out?

[@sohailnaseer7251]

Thank you so much for very comprehensive demonstration of Repository pattern. Well explained

[@EvangelosLolos]

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.

[@jaycelila6258]

I know that you are the best guy in this town (youtube tutorial town).

[@dasiths]

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.

[@fatemalokhandwala3477]

Amazing Explanation. Gained a lot of precise information in a very short span. That's what I love most about your videos.

[@wittttttt]

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?

[@geoffjames992]

+1 to that! I'm eagerly awaiting a video on implementing UoW in ASP.NET, as Mosh mentioned in the video.

[@chudipalchudos408]

Please, make a video about using UoW in ASP.NET MVC with IoC/DI...

[@divyang8utube]

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?

[@orangetimes2799]

You can use lazy intilization, and only initilize if someone needs it

[@viewtifulviewer7282]

yeah! I encountered exactly the same issue...I abandoned the unit of work, and used the repos...

[@wilko6524]

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.

[@haraldschaffernak9517]

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.

[@haraldschaffernak9517]

+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().

[@haraldschaffernak9517]

+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(); } ... }

[@haraldschaffernak9517]

+Programming with Mosh Thanks, this makes sense.

[@oneworldnoborders]

Thanks! Great and clear. I think your Iranian. Long life you and Iran.

[@tvbox4387]

Very well presentation of Repository! Greetings from Bulgaria!

[@yannikab]

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!

[@salimmapande4668]

Thank you Mosh, Thank you for a very comprehensive demonstrations of repository pattern, I enjoyed it for sure

[@hoomanbahreini2633]

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.

[@Arhnuld]

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.

[@subashp3226]

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)

[@psyaviah]

@@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.

[@ManishKungwani]

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.

[@RagingMonkee]

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.

[@anastasiyamartynyak6440]

just million likes!!! thank you so much!!! many many thanks!!!

[@nashanharis3398]

Excellent Tutorial. Thanks Mosh.

[@JodieLogan]

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!

[@AhmedHabbachi]

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.

[@irvlennert3674]

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

[@00l4]

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

[@santoshkmrsingh]

Extremely well explained the theory is key to implementing any concept and you do well to explain the same.

[@RagingMonkee]

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.

[@marc2377]

I just migrated from exactly that implementation to the one in this video as this one makes much more sense and actually reduces work.

[@ckmicpan]

thank you for the video. I think it describe the best way to implement a basic Repository Pattern. :-) I have some questions: - it is mandatory, in your opinion, to create the domain context inside the unit of work? i know it is convenient to pass the whole unit of work in the interactor constructor using dependency injection, (if i use clean, for example) but i don't like the idea of ​​creating so many of repository instances if it is not really necessary. - it is not better if we resolve the repository and the unit of work with a IoC container? (autofac, for example)

[@mryildiz702]

It's the best video/article/lesson I have found on the internet. Thank you :)

[@WayneGreen-g8l]

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?

[@geoffjames992]

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!

[@tuanbk08vn]

really easy to listen, easy to understand! Thanks

[@ttatum]

Thank you Mosh. Outstanding presentation!!

[@nirman1983]

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

[@VivekChandran26]

Brilliant and easy to learn presentation, Mosh. Hats off to you. Thanks a ton and please keep it up 🙏👍

[@FortyTwoAnswerToEverything]

Excellent presentation Mosh.

[@sundar2574]

could you please send me the source code?

[@joordanyt]

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.

[@pilotboba]

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/

[@balazs.hideghety]

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).

[@balazs.hideghety]

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 (kzbin.info/www/bejne/qKW7oYymj8mCsK8). 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...

[@volodyasenchak1907]

Really good explanation of Repository pattern.

[@amanthakur1987]

Excellent, I was struggling to understand repository realtime use...Now I know it.....Thanks Buddy.....

[@amanthakur1987]

Hi Mosh, do you have any video on Factory vs Abstract Factory scenarios??

[@StuartLoria]

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.

[@truebitoy1597]

very clear explanation and clear diction of voice, you just earned your first subscriber ;) keep 'em coming 'mate!

[@truebitoy1597]

+Programming with Mosh holy guacamole! I didn't see that, I guess KZbin is planning tricks on me lately. I really mean it, there's no subscriber count on your channel :P sorry about that

[@dibley1973]

Why has this only got 62 up-votes? This is a wonderfully clear tutorial. Thanks for posting it.

[@dibley1973]

+dibley1973 - What is more how the hell has it got two down-votes? What numpty down voted it?

[@atiqbaqi]

23:00 how should I do it in ASP.Net MVC project?

[@arechj]

Wonderful teaching - so useful and elegant! Thanks as always Mosh!

[@warriorfb2010]

Fantastic video. Really sums up a lot of questions i had

[@Weblogic81]

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.

[@ParamjeetSingh-vk4md]

Excellent video to demonstrate repository and unit of work.. Thanks a lot!!

[@Siyamsalam]

man..... you are just amazing. often your way of thinking reminds me how exactly I think...... keep up the good work.

[@arekw6012]

Amazing video! But what about Services? Should they be used a long with the repositories? If so, what should be their role?

[@padiau78]

There are different types of services in DDD. Application services sit on top of the domain. They typically load an aggregate (cluster of entities) from the repository, then call one or more methods on the entities to perform the desired operation and then save the aggregate back to the repository. The mistake many people make is that they put the domain logic into the application services, instead of the entities. This is what Martin Fowler describes as the “anemic domain model” and is generally considered bad OOP. However, in some cases, there might be logic which does not fit well into an entity. In that case it can be encapsulated in what’s called a domain service which is internal to the domain. But domain services should be the exception, not the rule.

[@rajanir9761]

Great explanation...very clear cut....help me understand this pattern and how to implment it nicely...

[@dsmyify]

Thanks Mosh! You're the real MVP!

[@otmanighoulassen6177]

Excellent video ! very clair and concise explanations, thanks a lot !!

Great!

[@AhmedHussein-vz4ux]

Very good tutorial and explanation. Thank you

[@Vahi]

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

[@ArberAWP]

Hello, good presentation. I am a .net dev myself and I enjoyed this video. Can you provide more info on updating an item from the generic repository? Preferably I'd use Interface to do that (with DI)

[@CybeargPlays]

21:00 Why cast Context as PlutoContext every time to get your Courses DbContext instead of continuing to call Context.Set() to get the DbContext you need, like you did in the Repository class? Is there some major performance cost that is avoided by simply casting?

[@impeRAtoR28161621]

@Mosh 21:58 you "hardcoded" repositories. How to use DI here and also be sure dbcontext is always same. Also, unit of work is missing concept of transaction? I often want save something (get id), then save something else. So, unit of work should have transaction.commit and repositories could have save inside them?

[@siddheshswa]

Excellent presentation Mosh. You really made it simple.

[@jovicamilenovic2899]

You said that that one point for using the repository pattern is decoupling the application from the underlying ORM. But if you supply DbContext (System.Data.Entity) as a parameter to the repository constructor it is coupled to the EF ORM, right (at 17:08)?

[@mvvassy]

very well explained. Also nice quote "Use patterns only when you need to. Don't use them as deodorant to smelly codes, smell good."

[@TheLegoody]

you're a superstar mosh. this really helped me a lot

[@kamdemkakengne]

Nice and clean ! I like the way you explain things ! Thanks a lot Mosh !