Repository Pattern | ASP.NET 6 REST API Following CLEAN ARCHITECTURE & DDD Tutorial | Part 3

Follow me on 'em socials:

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

[MilanJovanovicTech]

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.

[burjisazrael]

Yes, please make a specific specifications video that specifies how the specification pattern can be specifically implemented! :D
Anyway, great video!

[amarul]

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.

[bswill]

Thank you!! I think this is the only clean architecture video that was explained properly. Keep going sir, Im a big fan.

[arulmv]

You watched all 3 videos, it's great. Waiting for next video

[borisgomiunik]

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 not much, but a nifty speedup when structuring.

[manumm]

In DDD, actually domain object creation logic should be encapsulated inside repository using well defined domain factory. Your videos are very good and informative

[danielacevedo]

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

[mattsage]

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!

[buuzijslv]

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.

[chidii]

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.

[mohammadkalbouneh]

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

[bfg]

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.

[zgodhyh]

Great video. I love the way you present each of the topics

[georgekalokyris]

That was awesome Amichai. Keep up the good work.

[jamesevans]

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.

[joaofbvieira]

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.

[fadygamilmahrousmasoud]

i am really learning a lot from your videos .. thank you verrry much for your efforts.❤❤

[chadneiro]

Great tutorials. looking forward to the next part in this series. Watched the first three back to back. Thanks for making these.

[marna_li]

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)