Practical clean architecture with EF Core database first

[@ma-arufburad8826]

Thank God I found this tutorial. Thank you so much sir. This is very clean structure.

[@Codewrinkles]

Glad to hear that!

[@pureevil379]

This is great! I wish this video was out & I watched it before I started my database first project. I knew I could scaffold from DB and even specific tables, but there was so much that was brought down into the db context that it overwhelmed me. I decided to create everything manually, adding entities I made that matched the db tables ensuring I set nullable to nullable, types correctly and often ignoring keys I did not need inside of the application I was building and also ignoring fields completely from the entity model I created as there are hundreds and I only needed 5. This method I ended up implementing I actually ended up liking as any change to the DB fields (other than deletion and data type change of fields I implemented which would break my code regardless) could be ignored. I don't care if new bools are added to the table as my app has all the fields it needs. If I needed new persistent types I'd add them to the DB and to my models. I also skipped the rich domain model and opted for anaemic anyway. With all the logic occurring in handlers. I think if I was to scaffold have some rich domain model and didn't want to bother with separate classes I had to map to separate DB from Domain I'd use partial classes with the partial class representing all the 'logic' I added and the other being what a scaffold gives me. This would allow for updating of my model and my partial class providing the logic (maybe these would have to be split between domain project and application project as to not --force the scaffold to remove both? Not tried yet.

[@TreehuggingLiberal]

Thank you so much for that specific clarification; too many answers on Stack are so non-commital about where to do where to do the mapping from entities to domain models! That is precisely the answer I have been looking for.

[@Codewrinkles]

I'm glad you found this video useful.

[@Juznik1389]

Only seen a couple of bits of this video and I'm already learning a lot! Thank you mate! Gonna watch everything tomorrow!

[@Codewrinkles]

Glad to hear it!

[@SvMsk]

Thanks for sharing the knowledge! I have a question, since the mapping is done manually here, it works fine with querying data, but what about saves? If we follow repo/UoWpatterns, the Add and Commit/Save operations are separate, so, when you add an entity to the Repo and then save, EF wouldn't propagate the entity back to the model you sent since the domain entity is different to the db entity tracked by the EF context. So you wouldn't know the ID of the created object right? How would you deal with this?

[@JJ-hg7um]

Hi Alejandro, I had the very same problem. I've solved it by creating IIdentifiable interface in the Application Layer. public interface IIdentifiable { int Id { get; } } Then I implemented this interface on my DB entities, and returned this interface from the Repository Add method. In this way you will be able to read the ID in your command handler class and assign it to your Domain Entity. I believe there are better solutions, but this is what worked for me so far.

[@sergeyt4118]

very practical and useful as usual, thank you

[@Codewrinkles]

Glad you think so!

[@mahmoudzeort7078]

Great !Thank you for your helpful, in depth, recommendations

[@Codewrinkles]

My pleasure!

[@ub08022]

Do we need DTO to map domain modal to pass to client or we can use domain modal directly to pass to the client?

[@maximelarochelle]

If I have multiple repositories and sometime a handler update occurs in more than a repo how should I save my changes. Should I implement Unit of Work? Should I simply call save on any repository since it is the same context?

[@fadidib8516]

Loving this channel.

[@DongoBongKong]

As a general rule Interfaces should be defined in the layers that consume them, i. e. the interface of application services should be defined in the API or UI project and the implementation in the application layer

[@Codewrinkles]

I agree and I have discussed this in the Dependency inversion: kzbin.info/www/bejne/eYK2mamDead2qdE

[@birgirkarl]

Great video. Thank you

[@chinthanagunasekara7469]

This is grate. how implement the generic repository and UOW like this situation ?

[@juankasem4911]

Thanks for the video, In the clean architecture pattern, we, ideally, have the domain models created in the the Core/Domain layer. Where should the data models (database entities) be created? should it be in the Infrastructure layer or still in the domain layer but under a separate folder? , one other thing in case of Create function, where is better to implement the classes mapping, in the repository class or in the command handler class?

[@Codewrinkles]

Just like it is in the video, the generated data model entities should be in the DAL/infrastructure layer (DAL is still infrastructure. It's a matter of preference on how you want to name it). Mapping profiles and all related logic to convert the data model to domain model should also be in the DAL/infrastructure layer/ The way I like to think about things is like applying the SRP to entire layers. What should be the responsibility of the DAL? Well, to work with data and present it in a usable way for the application to work.

[@juankasem4911]

@@Codewrinkles so having data models & domain models is applicable in code-first approach scenario too, and not exclusive to database-first approach, right? (I am asking this because in the Clean architecture & CQRS series, the domain models were used in the DbContext class as db models).

[@Codewrinkles]

@@juankasem4911 In code first scenarios it doesn't really justify the overhead since you can apply EF configurations on the domain model and do whatever you want with it, without the model having to know that it's also stored in the database. By doing this in a code first approach you just add unnecessary boilerplate code.

[@juankasem4911]

@@Codewrinkles How can we use the same model for our business logic & for database store? (for example, how can we define a navigation property or foreign key in the domain model, or you suggest doing that in the EF configuration? in that case each domain model should have its own custom configuration.)

[@Codewrinkles]

The only concession that we'd have to make is that we have to add the navigation properties to the domain model. Anything else should be configured via EF configurations. There's also a video on this on the channel: kzbin.info/www/bejne/qIDbl2ywq8lkgqM

[@BhanuChander-p2j]

Hello Thank you. Where to add database transactions and the related logic?

[@user-be1on8zw7x]

Thank you video was very useful.

[@Codewrinkles]

Glad it was helpful!

[@mahmoudzeort7078]

Hello and thanks again. Just a question about Unit of Work that will wrap all the repositories. Of course, it will be defined, as follow : IUnitOfWork interface in Domain layer and UnitOfWork class in DAL layer ?

[@Codewrinkles]

Yes, if you choose to use it. But if you use EF Core in most cases you don't need a unit of work because the DbContext is a unit of work itself.

[@manliomarchica4911]

Great video really! Just a question: I used to see the repository and service interfaces in the Application layer not in the Domain, there is a reason put them in the Domain layer ?

[@Codewrinkles]

Yes, there is a reason and I even have a strong opinion about that reason :)) I usually don't have strong opinions, but this is an exception. This video explains exactly this: kzbin.info/www/bejne/Znu1emCuppZjr9E

[@manliomarchica4911]

@@Codewrinkles Hi thanks for the reply. In the video you linked I see that the repository interfaces are in the application layer not in the domain layer as you did in this video

[@Codewrinkles]

@@manliomarchica4911 Sorry, I guess I misunderstood the question. So, we agree that we should place repository interfaces in the application layer. If you go for a regular N-Layer architecture, then the interfaces would probably be in the domain.

[@arunbm123]

Thank You for highly valuable video...Where can I find the Code ?

[@Codewrinkles]

Unfortunately I don't have the code anywhere. Will try to change this for future videos.

[@vinland-h1w]

I really appreciate your video, it is really helpful but I'm confused, I'm new to CLEAN so is it okay to Infrastructure/DAL layer to reference into Domain layer? I thought Infrastructure layer can only reference to Application layer. I hope you can respond to this. thanks!

[@Codewrinkles]

it can for sure reference the domain layer. it's still an inwards dependency.

[@vinland-h1w]

@@Codewrinkles thank you!

[@petrbrozek5452]

Thanks for the video. What version of VS is this?

[@Codewrinkles]

That's actually not Visual Studio. It's another very popular IDE: JetBrains Rider. I use it because it's much faster and it comes with some great features that you only have in VS enterprise at astronomical prices.

[@petrbrozek5452]

@@Codewrinkles Thanks for the reply. So I'll try that as well.

[@maximelarochelle]

Where should I add a service like SendGrid? Should it be in another layer?

[@Codewrinkles]

This video is a little bit older and i don't recall exactly everything it contains, but SendGrid is used for sending emails and therefore it is an infrastructure concern. You can place it wherever you want in the infrastructure layer. Sometimes I have different projects that actually belong to the same infrastructure layer. And I have for instance Infrastructure.Persistence and Infrastructure.ExternalServices. I would place Sendgird in Infrastructure.ExternalServices. But if you have only one infrastructure project, you can place it there.

[@maximelarochelle]

@@Codewrinkles in this video DAL = infrastructure?

[@Codewrinkles]

Yeah. Data access is also infrastructure. Everything that talks to external system or physical computer resources is infrastructure. Data access is just a special kind of infrastructure on which we rely a lot in our applications.

[@CarrigansGuitarClub]

In your video @23:06, line 13. Why are you adding the DBContext - would the DAL only use DBContext?

[@Codewrinkles]

The reason I add the DbContext is that we want to make it available through dependency injection. So we need to add it to the ASP.NET Core DI container.

[@CarrigansGuitarClub]

@@Codewrinkles When you say DI dbContext, is that for 16:00 into the PaymentRequestRepository ctor?

[@Codewrinkles]

@@CarrigansGuitarClub Yes. I have several videos on service registration in Asp.Net Core, the DI container, service lifetimes and so on.

[@jovokrneta1412]

If we are ok to have the same looks of our domain models as our entity models, would it be ok to cut/paste entity models to domain folder. I am starting to develop an app and have full PostgreSQL DB in place, just need to replicate everything. Remapping everything all the time looks like an overkill for work and performance.

[@Codewrinkles]

Probably most people would say you shouldn't do this. And if you are using the exact same classes I also tend to agree. Why copy and paste them and not using them directly from the the assembly where they arescaffolded? Probably most would answer "to stick to clean architecture". However, in this case, as you are just cutting them, why should you take this extrasteps? You would have to update them whenever you perform a new scaffoldoperation.

[@CarrigansGuitarClub]

Is the model "PaymentRequest" in DAL needed if yo are referencing the model in Domain?

[@Codewrinkles]

Can you please point out a segment of the video you are referring to?

[@CarrigansGuitarClub]

Is it OK to move the DAL into a Service in Infrastructure (dbContext & EF models) and not have a DAL prj?

[@Codewrinkles]

I hope I understand correctly but I think this is just a naming thing. Data access is infrastructure so you can put in in an "Infrastructure" layer. However, usually the data access code becomes fairly large and I prefer to move it into a dedicated project called DAL. But in the end, it's still infrastructure.

[@venkateshn7171]

What is the use of mediator and CQRS

[@Codewrinkles]

First of all, I want to underline that what we do with MediatR is not full-fledged CQRS. It's just going in that direction. Now, coming to MediatR, it provides you out of the box interfaces and the necessary wiring to just send a query/command to the mediator and it will pick up the appropriate handler and execute it. Without MediatR you would have to code this yourself. It's not too complicated, but in production apps the time to market if really important.

[@CarrigansGuitarClub]

Do you have a link to the code?

[@Codewrinkles]

Thanks for asking. Codewrinkles ambassador members get access to the source code of each video I publish. For older videos I provide source doe by request if available. The source code for this video is available. So, please join as an ambassador member for source code access: kzbin.info/door/yTPru-1gZ7-4qblcKM0TiQjoin