Repository Pattern | ASP.NET 6 REST API Following CLEAN ARCHITECTURE & DDD Tutorial | Part 3
Вставка
- Опубліковано 12 вер 2024
- Link to the full playlist: • ASP.NET 6 REST API Fol...
Become a Patreon & get the source code: / amantinband
Follow me on 'em socials:
Twitter: / amantinband
LinkedIn: / amantinband
GitHub: github.com/ama...
What is this series?
We'll build a REST API following Clean Architecture & Domain-Driven Design principles completely from scratch.
We will use .NET 6, EF Core, and common patterns such as CQRS, unit of work, repository, mediator, and more 💪🏽
We'll also use some awesome open-source libraries such as MediatR, FluentValidation, ErrorOr, Throw, Mapster, and more.
The developing environment will be visual studio code & dotnet CLI only. We will use awesome vscode plugins for everything from sending HTTP requests to connecting to our SQL database, debugging, and peeking at JWT tokens.
We will code and refactor multiple times to tackle the many concepts I want to teach. When the series will be over, you'll have a good understanding and intuition on how to use these patterns & libraries in your industry-level applications.
How often will a new part come out?
Once or twice a week.
What are we doing today?
Today’s video is all about the repository pattern: What is it? Should I use it? And why is it so polarizing? We’ll dive deep into the repository pattern, learn about the pros and cons, and implement the user repository in our Buber dinner project, which we’ll use to wire up the register and login endpoints.
#dotnet
Yes, please make a specific specifications video that specifies how the specification pattern can be specifically implemented! :D
Anyway, great video!
lol, its a specifications family :)
Even though we're practicing DDD, I feel there is a need for us as developers to be practical when necessary.
For example, when checking if a user exists or not I personally create a method on the repository that would call "Any()" on the DbContext which would be translated to a "SELECT EXISTS" query underneath. Much more performant, and we're not loading everything into memory for a null check.
Completely agree. I like to look at all these design patterns and fancy words as tools, not rules
Absolutely. Pure DDD would be very slow in backend applications. There is an article called "DDD Trilemma". Really nice reading on this problem
A repository is used to access a collection of domain objects. It is typically oblivious of the underlying data store. I typically call a QueryService (facade) from the repository that actually accesses the underlying data store. There is no performance loss here
TBH i dont think DDD is worth it. The team will devout their time in creating the perfect DDD code for years when suddenly the project undergoes a complete revamp or worse, the project is dropped. Design patterns should help developers not constraint them unnecessarily.
@@ProtectedClassTest I think there’s DDD as practiced in code which I loathe, but there’s DDD as a set of principles which I love (eg bounded context, ubiquitous language, etc)
IMO the c# community interpretation of DDD is problematic
Great video! I like how you explain about the dicey DDD topics and don't say this is the right or wrong way but just explain them.
Hi. Really great videos. I've been watching the first three so far and I love the way you explain things. You and Milan Jovanović are very good advocates of DDD. Just as the need to give some helpful hints, when you're creating folder and then a file in the folder, you can actually create them at the same time - just add new file and combine folder and filename in the same - e.g. new file Persistence/IUserRepository.cs. not much, but a nifty speedup when structuring.
Man you are keyboard ninja with that VIM extension + all the shortcuts. 🥷 I think it's a great topic for future video where you could highlight some of the "productivity" hacks in you dev-flow.
I love keyboard shortcuts 😂 I'm planning a video on vscode for .NET developers where I'll cover vscode tricks. And I'll definitely do a vim series in future, gotta spread the cult 😁
In DDD, actually domain object creation logic should be encapsulated inside repository using well defined domain factory. Your videos are very good and informative
In the final result we will create all domain objects using static factory methods
Loved the videos so far, watching your content is not only making me to learn new things but emphasize that the way I think and do things aren't to wild and wrong after all
Great video! I've always put the Repository Interface in the Domain Layer, instead of the Application Layer. There's arguments for both and I still don't know what's best!
Thanks Matt. That's another dicey topic with good arguments to both sides. Personally, I default to application layer for repository interfaces
Important thing about Repository pattern is that it mostly comes in a bundle with Unit-Of-Work pattern. Imagine you have a class that modifies both User and Dinners - it's unit of work that responsible for them to have same EF DbContext (on same DB), otherwise they won't run in transaction. This is why naturally Repository by itself shouldn't have Save method rather delegating it to UoW.
Agreed. I get frustrated when I see saves inside concrete implementations of repositories. The UoW/Repository combination is a nice abstraction for some projects but can become overkill or limiting for others. If I use it, I tend to wrap a concrete implementation of a service around injected UoW/Repositories and just reference an interface for the wrapper service in the Application project.
I agree, although as Neil said it can be overkill for some applications. UoW will have a dedicated video (or 2) when we dive into persistence 🙂
You watched all 3 videos, it's great. Waiting for next video
Awesome to hear 🙏
Thank you!! I think this is the only clean architecture video that was explained properly. Keep going sir, Im a big fan.
Another great video, thanks again for all the hard work putting these together, much appreciated - I think repos can be very useful but I wouldn’t always use them. In my current app I do use repos for two main reasons, to abstract how the database code is implemented (we sometimes read from tables, views and stored procs) and the second reason is we need a standard abstraction to read and write a domain model as we have some common services which use the IRepository but the domain models are not just database entities i.e the content of a table, we have to join many different tables to construct the fields for the domain model, so we can’t use the DBContext which really just represents a table.
I'm implementing the repository pattern into my application specially that i already have old DAL layer that uses packages inside oracle database and schemas and I'm watching videos on clean architecture to implement what i have in a correct way and your videos are already helping since I'm new to clean architecture
Its very cool to review some topics and check others opinions and points of view. Can't wait for the next video! Congrats for the excellent content.
Great tutorials. looking forward to the next part in this series. Watched the first three back to back. Thanks for making these.
Awesome to hear, thanks Chad 🤙
At the end of this video during the refactoring, in the Infrastructure layer we reference the User entity from the Domain.. That means the Infrastrucuture layer knows about our Domain.
I think this is becuase Infrastructure layer has reference to Application and Application has reference to Domain. So Infrastructure can access the Entities of Domain layer. I thought the whole idea is to make our Infrastructure layer unware of the Domain layer.
@Amichai Mantinband I love your content so much and the way you teach.
Thank you for this video. You made me understand the purpose of Repositories as a concept. One possible alternative to creating an abstraction that is completely hiding EF Core away is extension methods on DbContext to fetch the Aggregates (if you do DDD)
Really Grateful for doing such extensive explanation on the topics, would you please add a video on unit test as well as part of the same series
Yes, I’ll have a sections about testing
That was awesome Amichai. Keep up the good work.
Great video. I love the way you present each of the topics
thank you so much for these series
How is it that the infrastructure layer was able to use the domain layer? The repository is using the User entity. I believe this is transitive project reference. Even though the Infrastructure project is not referencing Domain it is transitively through the Applicaiton. When I build layered project that I want to enforce referencing I set DisableTransitiveProjectReferences to true to prevent crossing boundaries. Should there be model objects or something in the Application layer (DTOs?) then map from the Domain to Applicaiton. Then the Infrastructure would use the objects from the Applicaiton not the domain.
The same happens with the Presentation layer with the application returning User from domain instead of an object from the Application. The Api is now using a Domain objects.
One thing I didn't get in this video is why was AddScoped used instead of AddSingleton for the repository? I tested the code with AddSingleton and it seemed to work just fine. Wondering what the differences are between those two.
Same here - confused by this. And if 'scoped' is preferable, why are the other two singleton???
Thanks, Amichai. Hope you are safe!
Nice. You're using functional patterns. You're also not throwing errors, but returning them. 👌 I recently discovered Language-Ext and started using it. It's great! 😊 - makes me want to learn F# too. 😆 Are you a fan of F#? Do you use it @ Microsoft?
Yeah, ErrorOr is actually from a library I released a few weeks ago. Wasn't loving the existing solutions when it came to my practical usages (I'm talking about OneOf, Maybe, Option, Result etc').
One of my next videos will be about error handling using this pattern and the other approaches for global error handling.
Never used F# (personally or in MS), very curious about it though 🤓
Definitely would appreciate a video covering UoW and DDD. I understand what is a domain, but whenever I read DDD, it always seems to be concepts and no examples.
Yup, that was my main motivation in creating this series. We will cover unit of work as well, don’t worry 🤙🏼
Nice video.
I don't think there's anything wrong with adding an abstraction for the data layer. Then, logic can be tested in a separate layer, independent of the technology. Even with the temp DB that the newer EF Core provides, there are still limits (e.g. executing raw SQL) and having a data layer increases test coverage.
However, if that's all that we're doing, then it's just creating an interface for the data service -- something that we do with all services -- so why does it even deserve to have a new name ("Repository")?
But for most of the examples that I saw back when the repository pattern was gaining popularity also came with implementing a generic IRepo interface (Get, Create, Update, and Delete methods). That allowed for generic code to be reused with caching. However, it also meant a lot of throw new NotImplementedException() s and if you wanted to add a GetBySomeNonKey, that wouldn't work with the generic stuff, either.
Finally, there was also the problem that since it occurs in the first half of the GoF book, people overemphasized its importance. I believe Evans is on record saying that while Ubiquitous Language is a core tenet of DDD, the repository pattern was just an implementation and not a core concept of DDD.
i am really learning a lot from your videos .. thank you verrry much for your efforts.❤❤
Generally the exsistance check of a database object and a creation of one inside the database should be in one transaction that should protect the database from changing its state, i.e. addind this object by any other process
I think Repository is totally unecessary when using EF, 'cause the context is already a kind of repo.
But using Repository, it works fine in simple scenarios. When you need to control transactions through 2 or more entities and you are commiting changes in the repository, you have a problem.
Can I use UnitOfWork and commit in UOW? Yes, but for me is redundant.
The context already provides all these methods. You can mock EF Context easily.
So for me repository pattern is reinvent the wheel
This guy's real smart. Period
I just a Func delegate into the IRepository class so you can provide your own queries. That way you keep dbContext where it belongs.
Great tutorial, waiting for the next content
Again Superb Video! Thanks!
Kindly find below some questions and elaborate on them.
1. Why has a JWT object been created as a singleton? However a user object has been added as scoped?
2. Why has a user repository class been added in the infrastructure layer instead of been added to the application layer ?
Hi Sudhir, really happy to hear you liked the video, and thanks for the great questions.
For both of them, it really depends on the implementation. If your class uses scoped services for example, then your class must be scoped or transient. If you don't have any limitations from dependencies that you are using, you would generally want to create as little instances of your class as you can. This means that if you can have your class Singleton, without concurrency issues or privacy/security concerns, it would be better than defining it as Transient and having it instantiated multiple times. Does that make sense?
Great informative video , Thanks for sharing your knowledge
Fantastic series so far
Thank you for the insightful explanation.
While your approach deviate from the precise definition and intent outlined in Martin's book regarding the Repository pattern, what is wrong with having pure and rich domain in your Domain and embracing ORM inside your command handlers in your Application as well as using a simple IDbContext interface with DbSet and SaveChanges inside your Application just for dependency inversion with Infrastructure without hiding and cutting the leaves of EFCore? In addition, using meaningful extension methods to addressing the mentioned readability issue.
Thanks for great video! I just wondering why do you use AddScoped and static field for in memory repository instead of using of AddSingleton
It doesn't matter in this case, both would work
@@amantinband So how come the other two are singleton? What's better? (thanks - great videos!)
Great contents...! Love you from Viet Nam.
Am I missing something or is the User entity in the domain layer now imported (or better a dependency) in app and infra layer? wouldn't that be against clean archs "We don’t want to cheat and pass Entities" for the reasons of Common Closure and Single Responsibility Principles
What would be your "real" fix instead the naive one shown in the video? Only Specifications? Did you explore any other ideas? Thnx
Nice and high-quality tutorials, thanks for sharing your valuable knowledges
I'm wondering why AuthenticationService is in the Application layer, shouldn't it be in the Infrastructure layer?
Great content , thank you sir, i watched all the 3 vids, keep it up please :)
Wow bro! I love your content ❤❤
Keep the good Work
Excellent content !!
I often forget how different the "norm" for software development differs from my views
I see the repository pattern as shown here as clearly being an alternative to an ORM like entity framework. It wouldn't make sense to build a repository on top of an ORM -- unless you're using "repostory" to just describe a dependency-injection module that gives specific ORM collections or something that gives common query fragments which your ORM library can use (the latter of which can resolve the second negative in this video if your ORM of choice supports combining query fragments). Meanwhile, when presenting the "negatives" of the repository pattern, your first point seems to take not just an ORM but entity framework in particular for granted.
This isn't something I considered when trying to make predictions about the video since ORMs aren't something I consider in general. I believe that obscuring the difference between normal object collections and data access is a common cause of friction and excess database access. I was aware the majority of developers still use ORMs, but I was still stunned to see not just ORMs but a specific ORM taken for granted.
I much prefer libraries that map domain-oriented query fragments to queries compatible with a given database model, leaving the boundary between data access and "normal" stuff still clear as day. When using a library like that, I tend to use the word "repository" to refer to something which provides those domain-oriented query fragments and the database context needed to run them, and such a "repository" solves the second negative in this video.
Could you let me know where the code hint 15:36 comes from? Seems it`s very smart and amazing!
Thank you so much for this great video. I also implemented a password encrytion class + interface. Just to be sure: I've put the interface into Application/Common/Interfaces and the implementation into Infrastructure. Does this sound right in terms on CA?
Thanks again!
Hi, great content and thank you for making it free. What book can I read for dotnet core specifically if I want the hard copy of this information? Thank you!
thank you
~~What about if the ID is database generated? Would you return the Entity from the repository on the command methods (Add/Save/etc)?~~
Oh I see, since it's an object passed by reference you could just access the ID generated from EF Core in the object you passed in.
This video is really awesome!
One thing that caught my attention is the tool that you've used to present the "flow" and the diagrams along with some squares to highlighting your points. How did you do that, could you share please? :)
Hey Thiago, Figma for all the visuals, ZoomIt for drawing on the screen
Great video, thank you 🙂 Can I ask what tool are you using for creating your class/arch diagrams?
Figma
I have seen projects implementing repositories on top of EF but they have never really used them for anything like this - like adding methods or aiding in unit tests. To be fair, they have not been DDD-projects. I think programmers just add patterns without knowing what they do. They just see Repository as a given abstraction without understanding the purpose of it.
Hi Amichai, would you recommand using the CQRS pattern for a smaller API or it's not worth it?
You talk about the specification pattern in this video, since you didn't make a video on it yet can I ask you about any reference libraries that implement the various specification pattern abstractions that you would reccomend? I'm considering either ardalis/Specification or writing my own but I don't want to invest too many resources on it if there are well-mainteinted libraries already. What would you do if you wanted to use the pattern?
What do you use to create these clean architecture images?
you are amausing !
what about the generic repository pattern, is it any good ?
Hey! How would you handle the case where you want to fetch only specific properties when calling a repository? By default EF will translate this to SELECT *, but if we are going to map only 3 of those properties to a DTO, it is not efficient to select the entire table. Do you think moving the mapping to DTOs in the repository layer is a viable solution where before the projection is materialized we map to a DTO and return it only with the properties we want?
U're awesome
Guys I need some help: In which project do you put the models and the db context from the database?
I have a question. We create a User as a domain model which is then used by the Application layer, IUserRepository. When the interface later is used by the Infrastructure Layer UserRepository, we use the User domain class due to it being on the method contracts. There is an indirect reference from Infrastructure --> Domain due to us referencing Infrastructure --> Application --> Domain which is fine as we cant avoid it. However, in this case the Infrastructure now need to know about the domain layer and also need to reference it as a using. Is this not bad from a clean architecture perspective?
Maybe we introduce dtos or something to not expose the domain classes outside of our application layer?
What would be other patterns to use instead of repository pattern for clean architecture?
18:59 when you register IUserRepository as scoped with in memory user list, the list gonna be null for the next http request. i dont know why yours is working
I would appreciate it you could answer to my following question: let's say that we have "User" as an aggregate, this imaginary aggregate has some behaviors or public Apis : register and modify. as you can see, me as a designer of this aggregate based on the business requirement, designed the aggregate by mentioned functionalities. now what would be the methods of the repository interface for this aggregate which in your design is located in the application layer ?
( what I wanted to say with this question is, domain layer is who that specifies the methods of the repository not the application layer !! application layer has not enough information to design the RepositoryInterface. let me know your idea)
How would you handle reports, that join multiple entities, while also abstracting away the DbContext?
can t u build another service that take from each entity ?
Reports aren't a DDD concern.
You would abstract the logic for them in a separate service, probably writing raw SQL with Dapper or calling a stored procedure.
@@fadidib8516 you don't want to do joins in memory over the whole dataset
@@bogdanb904 milan answer looks best.
@@fadidib8516 Yes, that's what I was also pondering about but wanted some kind of confirmation
Thanks you!!!
The infrastructure layer depends on the domain layer because of referencing the user entity. Shouldn't it be abstracted via its own class-dto-ish type, so that only the Application layer will ref to the domain entities? Greetings from Germany. Nice video!
Thanks! I don’t think another layer of abstraction is needed when working with EF Core. The database tables are already a mapping from the domain objects and can look completely different if needed
Hello, I have a question. Do I even need infrastructure project, when I am using DbContext directly? Since my app layer wouldnt know about the DbContext. I would need to install EF Core into the app layer. Thanks
It is relly awesome videos - but how come I have to insert lots of "using" statements when you dont need to - is there some kind of a magic trick I have overlooked? Thanks
(and I should now that
net6.0
enable
enable
is already enable project level)
It would be ok if i follow this project using mongoDb instead of sql/ef?
That's exactly why abstractions are made at data access, so you can use any type of store.
@@bogdanb904 Thank you!
What are you using for the code and comments generation??. It seems like visual studio code could read your mind!
Great video series. Thanks for the detailed explanations.
difference between DAO and repository? are they the same thing?
For a diner suppose I want to get the guest names. I will have Diner repo with GetDinerById(Id) method, and DinerGuest repo with GetDinerGuests(DinnerId) method. Then I will call these in the service or controller. 1st mtd retrieves the diner and 2nd method retrieves that dinners guests. Can you help me understand concept of aggregates in this example please?
Waiting for next video
What's part this series will have?
Isn’t it a bad Idea to get the payload (say for example an Article with small title and very large content) then only return the title which we are interested in? Or we can store the content in a different place and only retrieve it we we actually need it, say we only get the article for it’s meta data such as title and author… the content only after we want to actually read it? I guess you get my point. Please answer me
Yeah, that's a problem when the aggregates are very big and using the repository pattern to only fetch the aggregates in whole.
There are multiple options here:
1. Designing smaller aggregates.
2. For the query flow breaking the "retrieve aggregate by whole" and simply retrieve from the DB what's needed.
3. Creating separate models specifically for the query flow. These are models separate from the aggregates, designed to match the various views and are eventually consistent.
Let me know if this makes sense to you 🙂
I have a question, you are passing your contract/request as a parameter to service project. What if the contract is having lot of attributes. It is impossible to share it via parameters. How we can build a common model which is accessible in both the projects. Reference 20:47 you are converting result to Domain class but for request this is not possible.
same question happend to me, also at the end of the video User object which comes from Domain at the end is reachable and used in the third layer Infraestructure, If I understood well Clean Architecture definition says external layer does not need to know about internals... then why User class is used as parameter into JwtTokenGenerator service
How come the Infrastructure layer is referring to the Domain/Entities/user object. I thought according to CleanArchitecture the only layer that can see it is the Application layer.
It is a transient dependency. When A depends on D and I depends on A, I also (indirectly) depends on D.
I => A => D ... I --> D
Cant the hacker just try to register with that email and if the register fails that he can start trying with login?
19:24 What is the name of that VSCode extension fot http requests?
It's called "REST Client". I have a video all about setting up vscode for .NET: ua-cam.com/video/m9HvsB1-hAo/v-deo.html
I have one question: 14:24 you declare Add with user Entity, but is it a good idea? I mean it violates Information Expert pattern (or maybe i'm wrong), so is there any benefits of this? Or it just for simplicity for now?
Yes, it is intentional. The Repositories work with the domain models. Generally, you want to map the domain model to another model which will actually be stored in the DB. In this series, we'll be using EF Core which provides this layer of abstraction which allows customizing and mapping the domain model before storing it. But you can definitely have another object which represents the model you'll save. Does that make sense?
@@amantinband if you mean that EF should work with anemic models that represents data in database and repositories should produce domain models wih full functionality - i think i understand it. But i mean GRASP pattern Information Expert, but actually i was wrong and mistook it with Creator pattern which means that objects should be created by class that depends on. TLDR: i mean we can just pass content of fields to this method instead entire object. But i'm not sure this pattern is applicable here or there is some benefits of violates it here.
Actually i think i was wrong and there are no problems with this pattern. Maybe problem that i see actually can be solved by Factory pattern and at this point it's no such big deal.
I'm not a DDD dude, but to me it seems backwards to have the interfaces in the application layer and the implementations in the infrastructure layer. I would switch them around.
And some feedback on the video - the first two parts made it feel like it was part of a series while in this video I got the feeling that you tried to broaden the audience. To me that made it less connected and more unorganized. Like you wanted to please two different audiences. I think the first two videos gave a better picture of what you want to say.
Looking forward to the next vid!
What if you 2 or 3 different infrastructures? Table storage, sql server, etc. The interface does not need to know what will implement it.
I would switch them around too, but it doesnt matter much in the end I think, the important thing is to decouple with DI and IC
Having interfaces in the inner layers and implementations in the outer layers is a CA thing, not DDD. The idea is to push the dependency implementation outside so the inner layers can be agnostic to the implementation.
This series will cover many many topics from UoW to domain events so I want these type of topics to be standalone as well, for those who want to understand a specific topic or terminology, hope that makes sense 😁
The sad thing abut DDD is how much time is wasted on it's code-patterns. They're highly situational. What's important is the focus on (human) language and modelling of the essential flows of the domain. That said I always collect all code that uses the db-connection in designated classes/functions. If there is a problem related to the database and it points to the code, I know where to look.
Amazing video, thank you
Still think Clean Architecture + mediator is an anti pattern
So what is a better solution according to you?
Why? Could you elaborate?
Why?
@@amantinband Haha, sorry wrote that late at night and didn’t qualify it.
I think CA is a good principal to live by, but using projects to segregate the tiers of the application just to make it harder to accidentally couple tiers that shouldn’t know each other is overkill and not worth the overhead. The worst part is how it forces us to put Program/Startup in the presentation tier along with the DI registration - I think this orchestration should live in the application layer. My biggest gripe with CA is that the defacto solution structure is naive.
I think you could have the same impact by having multiple segregated DI containers, one per tier. And a good static analyser that can make assertions about your folder/namespace structure.
Speaking of orchestration, I think Mediatr (and nosy implementations of the mediator pattern in OOP) compromise the discoverability of the code. It is not conducive to quickly scanning the code, modifying in vertical slices or making deductive analysis of the code (eg you can’t say for certain that there isn’t rogue middleware that you can’t see). It is declarative, which is good practice for application orchestration but unfortunately not analyseable (because it’s orthogonal to the type system) so you can only run/test during runtime.
In any case, if your microservice is measurably benefitting from either of these systems, it’s not a microservice and you should reconsider your domain boundary.
I think a better approach, if you must use messaging and mediator, would be to have it centralised in a declarative form where you can explicitly lay out your execution pipeline in a way that’s obvious and easy to read (ReactiveX?).
Lmk if you disagree or have any questions. I’m developing my views all the time and interested in opposing view to help me refine my views. I’m responsible for the work of ~25 engineers so I need to be very sure before I say anything and I highly respect your views.
What do you mean when you say it's orthogonal to the type system? I agree about the vertical slices. Big downside having to modify at least one file in most or all projects when adding say a single field on a form that goes all the way into the DB.
I really liked this way of showing the "slides", can anyone share what tool that is?
Figma 🤙🏼
@@amantinband sweet, appreciate the response!
According to 17:57 Referencing Domain in Persistence will not break Clean Architecture
Hi @karthikeyanR87, I had a doubt on this and can you please specify why it will not break?
Hi, what the tools you use for making presentation?
Hi, all the visuals are made using figma
What is the tool you use to draw presentation diagrams?
Figma
So how can avoid this kind of Methods? You mentioned Specification Pattern can you maybe make a tutorial for that
I’ll probably create a video on specification pattern, perhaps even as part of this series
How to set up VSCode for .Net development like in your video?
I have a video about setting up vscode for .NET:
ua-cam.com/video/m9HvsB1-hAo/v-deo.html
Hi, why is your IDE so smart?
He is using github copilot
👌🙌👍
when part 4?
Tomorrow 🤓
@@amantinband awesome, thank you!
There is no need to implement the Repository pattern when you're working with Entity Framework.
The DbSet is the Repository Pattern and the DbContext is the Unit Of Work Pattern. So inside a class called "SomethingRepository" you're doing nothing but using and repeating the same codes from DbContext and DbSet. In another word, this so called Repistory is nothing but just a Wrapper.
And in order to not repeating the logics for getting an entity ById for example, you can simply write some extension methods for the DbSets.
Repository pattern also makes it too complicated for Unit Testing. A lot of people Mock the Repository and write their tests against the Repository.
And because of that there are always unexpected results and database errors just because we didn't write our test against the DbContext and database, but against a Wrapper or Repository.
Can you show me the example of a project that you do not use Repository pattern and implement unit testing in it.
And I dont understand the meaning of:
"Repository pattern also makes it too complicated for Unit Testing. A lot of people Mock the Repository and write their tests against the Repository. And because of that there are always unexpected results and database errors just because we didn't write our test against the DbContext and database, but against a Wrapper or Repository."
How Repository pattern also makes it too complicated for Unit Testing?
"And because of that there are always unexpected results and database errors just because we didn't write our test against the DbContext and database, but against a Wrapper or Repository" => Mocking in repository its mean we are testing without DB, how we can have " unexpected results and database errors just because we didn't write our test against the DbContext and database"
@@MinhTran-up3pg did you ever hear of InMemoryDatabase in EF?
@@pedramkavian No. And I waiting for your answer
@@MinhTran-up3pg InMemoryDatabase is one of of entity framework providers. It's a complete database but in memory. Microsoft created it for testing purposes. It means you can use the AddDbContext method and telling it to use the InMemoryDatabase. So inside your unit tests you simply create an instance of your entire DbContext and write all kind of tests that will be using your real DbContext and not a fake mocked repository. This is very useful because when you change your db models in your project and you have no idea that you broke some of your codes, the Unit Tests will throw the exceptions. But with a fake or mocked repository you will never know this. Just google for InMemoryDatabase.