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.
Mosh, I don't know if you still read this but I wanted to say THANK YOU for taking the time to go over the arguments that EF already implements the repo pattern, etc etc, and demonstrate that this is not exactly the case. This entire debate had me so confused for quite a while, and you did a _great_ job putting it to rest (for me, at least). The demonstration is also nicely done. Thanks, really.
I have done repository before and I am new to unit of work. My repositories have save and delete methods. The way you explain unit of work here has helped me a great deal I will be implementing this pattern much more often.
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.
Nice video. I tend to find for smaller projects Entity Framework is just fine for a repository and unit of work pattern as there is less if no duplication of queries. I have used your pattern before and found it to be too much for small projects. My only advice is: Do what is best for your particular project. There is no one size fits all solution. The solution posted in this video is great for a larger application.
I agree with you Mosh. Repository Pattern has become a mystery to me ever since I tried to explore it and for the most part articles from different developers have different implementations of Repository Pattern in which it is hard to determine which is actually the right one.
IMO, the “collection-like interface” is the least important and most out-dated portion of the repository pattern. The most important part of the pattern is to isolate the rest of your application from the persistence logic. You typically don’t want to reuse repository methods. Since your business logic shouldn’t be in the repository, you don’t want multiple code paths reusing a repo method like SaveArticle(Article article). Instead reuse the same service method that calls the repo so the same business logic is enforced. Too many coders try to get cute/clever with generic repositories, exposing IQueryable, etc. EF performs poorly enough all by itself. It doesn’t need help being slower by the n+1 problems created by not writing custom linq queries that specify the include. Of course it always depends on the specific constraints of the application. Thank you for your great videos.
I think you should have touched a bit on ".AsNoTracking()" and perhaps also .Attach(), EntityState.Modified and EntityState.Detached, since e.g. retrieving all courses without intent to change anything, is probably the most common use case. Then you can just attach the specific course when you actually want to change it, i.e. have Entity Framework track it for you. If all retrieved objects are tracked all the time, it's a huge impact on performance.
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.
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.
Find method in IRepository is breaking the rules of having the query written only once. A developer can inject any expression in it duplicating queries in different repository clients. I'd remove it from the interface and allow only named query methods. Specification pattern might be an alternative option but that in the end kind of boils down to the same thing.
I was searching 2 days for guide like that and everything was a trash, lessons without understanding the base... and only now youtube proposed me this video and it's perfect!!! My huge respect to author !!! Like and subscription :)
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
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.
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.
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.
5 років тому
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
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.
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,
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.
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.
Great tutorial, however there's one aspect which puzzled me a bit, namely the Find method which takes a predicate as parameter. Don't you consider this as a potential risk for leaking abstraction into layers depending on the repository. There are three potential problems I can see. Firstly, not every Expression can be interpreted by EF. Secondly, there's no guarantee that a predicate which works with EF is going to work with a different data access library (let's take OData as an example). Last but not least, if somebody is working in TDD style it might get a false sense of security by mocking out the Find method (all unit tests will pass but once the code gets executed against the real repository, the implementation will break).
+Simon Farrugia you would create your own repo Find method meaning that you use the parameter house you want. You can even create your own find arguments class if you don't want to use an expression
This. Apart from the Expression-Type being in the bcl, this is a leaky abstraction of EF. No way of implementing this for ADO or Dapper. It's interesting because he mentions Dapper in the beginning and then writes an interface which is nearly impossible to implement with a lot of ORM.
Repository in UOW is an anti pattern. And using the repository to get persistence model as well . I recomend for all of you lazy busters chek definition of Repository pattern and consider what mean "for accessing domain objects.". Persistence models of ORM is not a domain object this part of infrastructure that represent table in DB. He made some sort of wrap on ORM wich is not necessary if you'r using good orm like NHibernate.
You 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
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.
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
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!
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!
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(); } ... }
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.
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?
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?
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.
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
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/
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.
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.
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
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
So, from architectural side it's one of the best implementation i've seen, despite some flaws: 1) exposing DbContext from a repository is almost the same as exposing save method 2) unit of work lacks transactions. while EF DbContext does not do extra roundtrips and changes to the database until save is called, NHibernate does. But even with EF it's possible to execute custom SQL that would alter the DB and since with published DB context on the repository it's possible to do this, our unit of work becomes no unit of work in that case! 3) in this case also not the repository who's acting like an in-memory collection, but the db context, and also repository, and also the repository itself does not expose save (which is a wise decision in this architecture) - so it's not a repository pattern according to definition, but yeah, it does the isolation from the db code. 4) even if injecting just X repos into unit of work, due to the ORM and the traversible object model all DbSets (so all repos) will be accessible (so theres no real repo boundary) The querying can be done with query classes (per entity or even per use-case). The one thing I like with this repo patter is, that when it's applied correctly, it can serve as an abstraction for more complex EF logic - like removing orphaned children which EF can't handle via mapping).
Please don't cherry pick. Even if you use interface, you should take care on what you expose in your implementation. Simply there's no need for the context you use inside a repo to be public (ua-cam.com/video/rtXpYpZdOzM/v-deo.html). Furthermore: - In real scenarios you might need a mass update - custom SQL. In that case your unit of work (without transactions) might not do what it's intended. - Also your repositories do expose orm mapped entities, so they do not have real boundaries (so you did it right to put them into an unit). this part of your concept is really a good one. - Interfaces are really cool, but I assume you won't change the persistence layer and if you used the word domain, you should know that domain logic can be tested (even more easily) without repositories. So it's premature to introduce them. I still like this solution. But... I'd not use repos for: - forwarding ORM's CRUD methods - and neither for querying (for it we can use query classes, actually they are your repos without the CRUD stuff, but each query could be a separate query class, depends what complex search logix you build around it) For those, who thinks this is really an overkill (don't misunderstood me, I did similar architectures not a whole decade ago)...here's a simpler solution. 1) use query classes instead of repos 2) drop interfaces until you really need them 3) instead of coding unit of work use TransactionScope! the only thing to take care of is to create some transaction scope builder, where you can set your default isolation level (not serializable)... since you rarely need to manage 2 sets of changes inside a given thread, TransactionScope will suit most use-cases...
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!
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.
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.
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?
Thank you so much! I'm still a newbie when it comes to developing applications on my own and due my lack of experience I've searched for a long time and read one blog post after another. In the end I was so confused about the fact, when to use what and where to write down this sh*t :) Your Video sorted out a lot questions. Keep going with your great work. Greetings from Germany :) (Please ignore my bad english)
+Programming with Mosh holy guacamole! I didn't see that, I guess UA-cam is planning tricks on me lately. I really mean it, there's no subscriber count on your channel :P sorry about that
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.
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.
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?
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.
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).
Excellent video, as always... I was hoping to see the update shown. I would also like to see how MVC replaces the using(...) statements. btw, have you considered producing a hard-core MVC certification course? I would buy one, for sure.
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)
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.
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?
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
Mosh, I don't know if you still read this but I wanted to say THANK YOU for taking the time to go over the arguments that EF already implements the repo pattern, etc etc, and demonstrate that this is not exactly the case. This entire debate had me so confused for quite a while, and you did a _great_ job putting it to rest (for me, at least). The demonstration is also nicely done. Thanks, really.
I have done repository before and I am new to unit of work. My repositories have save and delete methods. The way you explain unit of work here has helped me a great deal I will be implementing this pattern much more often.
Right? That was so helpful
Excellent. Probably the clearest, most concise, and easiest to grok tutorial on the Repository Pattern I've ever watched.
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.
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.
Your "IRepository" has "Find" method with "Exspression predicate" parameter. How are you going to implement it with stored procedures?
"simplicity is the ultimate sophistication" and your training also simple & Clear about a complex pattern.
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.
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!
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.
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
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.
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!
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.
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.
Saw dozens of tuts but literally this was awesome simple and focused, I feel confidence now. Thanks a lot!
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 :)
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
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.
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.
Best explanation I have heard to date on the repository pattern. I am much closer to understanding it now
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.
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
Best explanation I've yet to see of the repository pattern.
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
This is by far the best explanation on repositories that I've seen online so far. When is your course on Pluralsight coming out?
Just wow, you completely blew me away with your well-cut explanations. Excellent job Mosh.
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.
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.
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,
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.
This channel is gold mine for C# Beginners and Aspirants.
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.
Almost 2 years and you still made a lot of sense.
thanks so much. You are the best
Great tutorial, however there's one aspect which puzzled me a bit, namely the Find method which takes a predicate as parameter. Don't you consider this as a potential risk for leaking abstraction into layers depending on the repository. There are three potential problems I can see. Firstly, not every Expression can be interpreted by EF. Secondly, there's no guarantee that a predicate which works with EF is going to work with a different data access library (let's take OData as an example). Last but not least, if somebody is working in TDD style it might get a false sense of security by mocking out the Find method (all unit tests will pass but once the code gets executed against the real repository, the implementation will break).
Very good point. Can anybody answer this please.
+Simon Farrugia you would create your own repo Find method meaning that you use the parameter house you want. You can even create your own find arguments class if you don't want to use an expression
This. Apart from the Expression-Type being in the bcl, this is a leaky abstraction of EF. No way of implementing this for ADO or Dapper. It's interesting because he mentions Dapper in the beginning and then writes an interface which is nearly impossible to implement with a lot of ORM.
Repository in UOW is an anti pattern. And using the repository to get persistence model as well . I recomend for all of you lazy busters chek definition of Repository pattern and consider what mean "for accessing domain objects.". Persistence models of ORM is not a domain object this part of infrastructure that represent table in DB.
He made some sort of wrap on ORM wich is not necessary if you'r using good orm like NHibernate.
Yes, truly abstracting away EF is difficult and, in most cases, pointless (YAGNI).
You 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
Amazing Explanation. Gained a lot of precise information in a very short span. That's what I love most about your videos.
Thank you Mosh, Thank you for a very comprehensive demonstrations of repository pattern, I enjoyed it for sure
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.
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
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
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!
My favorite video about repository pattern + unit of work video
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!
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.
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.
Very well presentation of Repository! Greetings from Bulgaria!
DbContext itself is the UnitOfWork and DbSet is the Repository pattern.
There is no need to repeat a pattern that already exists.
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?
Thank you so much for very comprehensive demonstration of Repository pattern. Well explained
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?
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.
I know that you are the best guy in this town (youtube tutorial town).
Brilliant and easy to learn presentation, Mosh. Hats off to you. Thanks a ton and please keep it up 🙏👍
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
Excellent explanation. Clearly understand about the Repository & Generic Repository pattern. Thanks alot
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/
The best explanation on Repository Pattern
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.
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.
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
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?
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
So, from architectural side it's one of the best implementation i've seen, despite some flaws:
1) exposing DbContext from a repository is almost the same as exposing save method
2) unit of work lacks transactions. while EF DbContext does not do extra roundtrips and changes to the database until save is called, NHibernate does. But even with EF it's possible to execute custom SQL that would alter the DB and since with published DB context on the repository it's possible to do this, our unit of work becomes no unit of work in that case!
3) in this case also not the repository who's acting like an in-memory collection, but the db context, and also repository, and also the repository itself does not expose save (which is a wise decision in this architecture) - so it's not a repository pattern according to definition, but yeah, it does the isolation from the db code.
4) even if injecting just X repos into unit of work, due to the ORM and the traversible object model all DbSets (so all repos) will be accessible (so theres no real repo boundary)
The querying can be done with query classes (per entity or even per use-case). The one thing I like with this repo patter is, that when it's applied correctly, it can serve as an abstraction for more complex EF logic - like removing orphaned children which EF can't handle via mapping).
Please don't cherry pick. Even if you use interface, you should take care on what you expose in your implementation. Simply there's no need for the context you use inside a repo to be public (ua-cam.com/video/rtXpYpZdOzM/v-deo.html).
Furthermore:
- In real scenarios you might need a mass update - custom SQL. In that case your unit of work (without transactions) might not do what it's intended.
- Also your repositories do expose orm mapped entities, so they do not have real boundaries (so you did it right to put them into an unit). this part of your concept is really a good one.
- Interfaces are really cool, but I assume you won't change the persistence layer and if you used the word domain, you should know that domain logic can be tested (even more easily) without repositories. So it's premature to introduce them.
I still like this solution. But... I'd not use repos for:
- forwarding ORM's CRUD methods
- and neither for querying (for it we can use query classes, actually they are your repos without the CRUD stuff, but each query could be a separate query class, depends what complex search logix you build around it)
For those, who thinks this is really an overkill (don't misunderstood me, I did similar architectures not a whole decade ago)...here's a simpler solution.
1) use query classes instead of repos
2) drop interfaces until you really need them
3) instead of coding unit of work use TransactionScope! the only thing to take care of is to create some transaction scope builder, where you can set your default isolation level (not serializable)... since you rarely need to manage 2 sets of changes inside a given thread, TransactionScope will suit most use-cases...
Excellent presentation Mosh. You really made it simple.
Great presentation, and a joy to apply. One question though. Is there a clean way to support explicit loading in our unit of work? Normally this is done through the Entry API of the DbContext, but the DbContext is hidden now. One could expose Entry on the unit of work, but this would allow the user to write queries outside the unit of work. To be honest, it's not very hard to remember to use it only for explicit loading and not queries, but I was wondering if there is a way to ensure it. Thanks!
It's the best video/article/lesson I have found on the internet. Thank you :)
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.
Excellent video to demonstrate repository and unit of work..
Thanks a lot!!
Extremely well explained the theory is key to implementing any concept and you do well to explain the same.
Excellent video ! very clair and concise explanations, thanks a lot !!
Wonderful teaching - so useful and elegant! Thanks as always Mosh!
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.
Hello Mosh,
Excellent tutorial.. Can you do the same topic with Database First approach instead of Code first approach?? Thanks.
Thank you very much. I will experiment this to understand more about.
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...
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??
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
Thank you so much! I'm still a newbie when it comes to developing applications on my own and due my lack of experience
I've searched for a long time and read one blog post after another. In the end I was so confused about the fact, when to use what and where to write down this sh*t :) Your Video sorted out a lot questions. Keep going with your great work.
Greetings from Germany :)
(Please ignore my bad english)
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 UA-cam is planning tricks on me lately. I really mean it, there's no subscriber count on your channel :P sorry about that
Very helpful. Great clarity in content and beautiful slides.
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.
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.
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?
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.
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).
Excellent Tutorial. Thanks Mosh.
Thanks! Clean and complex explanation, man
Very good tutorial and explanation.
Thank you
Excellent video, as always... I was hoping to see the update shown. I would also like to see how MVC replaces the using(...) statements.
btw, have you considered producing a hard-core MVC certification course? I would buy one, for sure.
Nice and clean ! I like the way you explain things ! Thanks a lot Mosh !
man..... you are just amazing. often your way of thinking reminds me how exactly I think...... keep up the good work.
Really good explanation of Repository pattern.
just million likes!!! thank you so much!!! many many thanks!!!
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)
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.
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!