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?

[@mykhailo-kmet]

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

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

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

[@BryanJohns]

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

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

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

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

[@jobycheriyan9740]

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

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

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

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

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

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

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

[@pierrenilsson4179]

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

[@sohailarshed3427]

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

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

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

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

[@david3552]

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

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

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

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

[@Pest87]

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

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

[@gauravpathare208]

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

[@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?

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

[@Gojam12]

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

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

[@roylee3196]

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

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

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

[@olawoleomotosho4836]

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

[@salimmapande4668]

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

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

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

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

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

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

[@tvbox4387]

Very well presentation of Repository! Greetings from Bulgaria!

[@fatemalokhandwala3477]

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

[@mshevroja]

My favorite video about repository pattern + unit of work video

[@siddheshswa]

Excellent presentation Mosh. You really made it simple.

[@pedramkavian]

DbContext itself is the UnitOfWork and DbSet is the Repository pattern. There is no need to repeat a pattern that already exists.

[@VivekChandran26]

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

[@Loveumica]

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.

[@israilkarud9293]

The best explanation on Repository Pattern

[@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,

[@user-nw8oi9vn9y]

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?

[@ParamjeetSingh-vk4md]

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

[@otmanighoulassen6177]

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

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

[@jaycelila6258]

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

[@sohailnaseer7251]

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

[@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)

[@allwynd]

Very helpful. Great clarity in content and beautiful slides.

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

[@arechj]

Wonderful teaching - so useful and elegant! Thanks as always 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!

[@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/

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

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

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

[@malikau917]

Thanks! Clean and complex explanation, man

[@mohsinmemon3362]

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

[@mryildiz702]

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

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

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

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

[@kazinix]

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.

[@marc2377]

Why Get(object[] keyValues) instead of Get(TId Id)?

[@marc2377]

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?

[@muzafferckay2609]

GetTopSellingCourses includes business logic as the definition of the top is a business rule. Check the specification pattern. I am not fimiliar with c# but I think your find method takes a entity related functions expression. This is tightly Coupling.

[@ssult066]

Hello Mosh, Excellent tutorial.. Can you do the same topic with Database First approach instead of Code first approach?? Thanks.

[@benripka6977]

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

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

[@BryanPollardPhotos]

Brilliant! Thank you for the clear and straightforward explanation of these principles.

[@SalahLFC11]

For sitecore it moght not have improved unit testibility but for other ORMs it does. Like, Sitecore CMS data can not be accessed using EF, there is different ORM called GlassMapper, here it surely increases unit testibility.

[@smitch_yt]

Loving your tutorials, very clear and easy to follow Thanks!!

[@volodyasenchak1907]

Really good explanation of Repository pattern.

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

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

[@pavfrang]

Note that the "predicate" used in the Find method, can be used only with DBContext and not in other frameworks such as Dapper. So it is not clearly "framework independent". Other than that, you use the Repository Pattern exactly as it is supposed to work!

[@padiau78]

Good explanation, but I think you are missing an important aspect. Ideally, repositories should work with aggregate roots, not individual entities. This helps a lot with managing complexity which is what DDD is so good at. On the other hand, writing a generic repository is a bit of an anti-pattern because it indicates that you are not working with clearly defined aggregates. As a result, a lot of logic around data access, maintaining consistency, and your data structure will leak into your application services, making the repository far less useful.

[@santoshkmrsingh]

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

[@AhmedHussein-vz4ux]

Very good tutorial and explanation. Thank you

[@kamdemkakengne]

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

[@x86cowboy]

Actually, NHibernate was out first because it was a port from Java's Hibernate; which predated Entity Framework v1. NHibernate and Hibernate were inspirations and impetus for Microsoft to create Entity Framework. The initial release for Hibernate was in 2001, NHibernate in 2005, and Entity Framework 2008.

[@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)

[@helloandrewgunn]

The repository pattern is dead. Don't abstract an abstraction like this. If you want to avoid code duplication, create extension methods on top of DbSet

[@PrafullakumarSahuprofile]

Hey Andrew, Just wanted to know more about your approach. if you have any blog post written then please let me know I would love to read.

[@helloandrewgunn]

@@PrafullakumarSahuprofile ayende.com/blog/3955/repository-is-the-new-singleton

[@nickbehrends9355]

I know this is old but: one of your goals was to decouple persistence from application. But you're still returning EF entities to application instead of generic types or DTOs. Also the Find(predicate) method directly leaks query logic Much bigger fan of the explicit methods you have but return only the properties needed for the business rules.

[@nightgamer8953]

Hi Nick, how should we return view model ? where do we convert EF Entity model to view model ? Is it done in controller or should we add additional Service layer and convert it there?

[@TheMoosaChannel]

I would like to take a look at a full coding including CRUD (Database First Approach). And I do hope it also uses multiple tables for CRUD (Like the drop down list of another table in the form to add/update).

[@stianskuland1762]

Great tutorial Mosh. The only thing that is unclear to me is how can it handle joins ? and how do i do it?

[@darryltaylor9282]

I struggle with this concept too; especially regarding models where there is a header/detail type relationship.

Great!

[@user-ob3qg2sf8s]

Just want suggest a small improvement. In AuthorRepository you can avoid cast "return Context as PlutoContext" by saveing Context as private field during initialization "public AuthorRepository(PlutoContext context)"

[@Yourzanny]

Awesome. Can you please make a video for all the design patters and explain which one to use according to the scenarios. That would be very helpful

[@nashanharis3398]

Excellent Tutorial. Thanks Mosh.

[@siddgoen]

Great explanation. One query - How do we handle the scenario when we need to join tables to return a different model or perform a domain operation which requires accessing multiple entities ? Should we perform these kind of operations in UOW class? If yes, should we use dbContext in the UOW class or have individual repository classes return IQueryable instead of IEnumerable to perform the join query in the UOW class?

[@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?

[@alokbabus]

Thanks for explaining. Could you tell me how to initialise a controller with other other services dependency injected along with Unit of work?