You're explanation is insanely awesome, no one talks about the n-layered architecture like you! they often put their domain models inside the Data Access layer!!! Not like you separated the domain model into a specific layer and made it below the Data Access layer so BAL and DAL both can use it. Thank you, sir.
Thank you so much for this video - it really clarified a lot for me. I arrived here out of frustration with my own "Fat Controllers" on a Web App MVC project: I knew my logic should go somewhere else but didn't know where to begin. This is the answer! Really appreciate you sharing your experience.
Thank you for this straightforward, practical and simple course. I'm new in asp and it's helped me to learn Clean and Layer Architecture both for my new project.
Hello Dan, First of all Thank you for the video. I have few questions , 1) In which layer should DTO Models be used? 2) How do we handle complex JOINS on multiple entities? If we do Joins, should we return IQueryable for GetAll Methods from Repository? ( Case - Db First Approach without Scaffolding ) 3) Where are Exceptions thrown? If we use Global Exception Handling, what happens? Is it a good idea to throw exceptions in the Service Layer? 4) Where should Custom Exceptions Classes go? 5) Where should the Request Model Validators Extension be located? (FluentValidation) Please assist me because I am about to use this Layer for our upcoming project (smaller one) Please advise if this is a good architecture to use.
Did you find answers for these questions? If so could you pleace provide them because I faced the same problem but can't find anything that would help to solve it
It depends. If you are following 100% clean architecture, then it shouldn't. If you go mostly for a CQRS pattern, then I personally don't see any problem working directly with the DbContext in each handler. That would introduce a dependency, but in this very isolated approach where each action in the application is handled by exactly 1 handler this is not a big problem anymore.
@@Codewrinkles i followed your beginner playlist but in the service layer i had a dependency to the Dal layer because we were accessing Datacontext in ResveationService class ,, is it wrong ? and how i can solve it or is there another way to do it ?
@@mohamedal-qadeery6530 To be honest I don't recall exactly how it was set up during the tutorial and maybe there were some pedagogical reasons why I did that, but usually in the Service you would Inject an IReservationRepository and you would inject the DbContext in the repository. This way, the Service layer would not have a direct dependency on the DAL. It would use just interfaces defined in the domain/core layer.
hi good video, how to insert update the api data into my database where we need to handle it. do my controller need to access dal layer to save the entities or the service after all the business logic are moved to service
I am very thankful to you, It is very helpful for me. Could we apply Data first approach using Entity framework with PostgreSql DB for same structure?, And it is giving me a circular dependency error. Thanks
Hi - Thank you for a very useful introduction and example of this architecture. I have seen comments elsewhere that the Web or API Layer should not have a dependency on the DAL. Is there any alternative way to Inject the Repository in Startup (or elsewhere) without having an explicit reference to the DAL project?
If your only dependency is in the Startup class or in Program class (if .NET6), then that's totally acceptable by all common sense and best practices. Your dependency is only that you add them to your DI container. An alternative would be using 3rd party DI library and place it in a "common" project, something similar to a shared kernel in DDD terms. But that would be an overhead that would not justify just a compile time dependency. I'm not sure where you have seen or read this, but it's the first time that I can say that it's total nonsense and an advice you should not follow.
Where can we apply identity operations such as adding user permissions and rules? Can we add it to a reusable repository?? Its connection string, especially in Blazor projects?
Identity operations are for sure part of the domain model. The model classes you need for that belong therefore to the domain layer. The repositories for it belong to the DAL and Idnetity Services belong to the services layer. For Blazor Server there's really no difference. For the client, you should never work with connection strings on the client. Information should be exposed via the API and authentication and authorization will have to follow OpenID Connect and OAuth 2.0 standards.
If you are using dedicated models for EF, then for sure in the data access layer. But usually when we work wit code first we simply re-use our domain models also for EF. As the data access layer will already have a dependency on the domain layer, this should not be any problem.
Great video! I have been looking into the service layer pattern for a bit. Would you say that this standard layer architecture somewhat adheres to that pattern?
Yes, it's kind of standard. There are a lot of projects out there that run just fine and use services. However, my preference goes towards a more decoupled approach using CQRS,
What about in case of reverse engineering. In case of reverse engineering I am not able to create domain and context class in different class libraries. Please give me solution for this.
Thanks so much, your explanation cleared my confusion of many days. In the case that I need to interact with the file system or email or Sms, where does not functionalities go? Do I create another layer; may be Common Layer or add the functionalities to the Service layer?
Those would be regular services in your service layer. You would have a FileService, an EmailService, an SmsService and so on. No need to create additional projects/layers for that unless your existing project gets overwhelming.
Is it okay to use multiple classes for Repository? I mean if a domain is too large and have couple of sub-domains, Is that okay to use different implementation of Repository for different sub-domains?
I'm really not sure what you are looking for. On this channel you have a lot of implementations with this pattern. Go to the ASP.NET Core for absolute beginner playlist, and there we implement an API following this architectural pattern. All the playlists that contain live coding sessions implement the different architecture or the other. Why does it need to be a weather API?
No, that would be a total different layer that actually doesn''t have to do anything with the API. You can think about this as a totally different application. I know that in the standard VS template for ASP.NET Core with Angular, the API and Angular is kind of in the same project. But that's totally wrong from my point of view because it introduces a lot of misunderstanding.
This was very interesting, thank you for explaining. I have a question though, can we use the same architecture with ASP.NET Core Web Application MVC ? I'm trying to build a Web Application and I need it to be well structured.
Hi! Shouldn't you use your own models on the web? If you were to use IMapper, where should it be placed? using it on the web, each page/controller will repeat the same logic. Going over that, for POST requests you will directly use the entity from Domain due to the argument of that type from Service. I am facing this problem, I am looking for a way to separate it as clean as possible
Thank you sir but can you please move your head on the screen so we can see the other files on the right side bottom. You can just use your voice while doing a tutorial. Great job on the tutorial tho :) thank you
It was very very informative.. 👍 ?As i have heard in the market there are onion, Domain driven , CLEAN architecture but not aware how these works, does this architecture in the video has any name?
@@sibaprasaddalai3775 My plan is to cover most of the architectures and how we set them up in our VS solution. Hope I'll be able to publish one on clean architecture very soon.
In your opinion, in this architecture, would you include Models which are not persisted to the database in your Domain layer as well? For example a WeatherSummary class which had less properties than the WeatherForecast and may be a return type from your Service Layer.
I think that there is a very common misconception that there should be some kind of mapping between what is persisted and what should be in the domain model. When I'm writing my domain, I don't care about persistence. I just care about modeling business behavior. What gets then persisted to the database is a whole different story. So, the answer is, yes, if WeatherSummary is part of business behavior, I would still put it in the domain. But from the name of this suggested class it seems to me that it is more related to the presentation of the data to a consumer and hence I would probably consider placing it in the presentation/API layer as some kind of DTO or ViewModel. My service layer would return the domain objects. The presentation layer is then responsible to aggregate them based on what needs to be shown on the UI or returned from the API.
@@Codewrinkles Thank you for the response, this makes sense. So in your opinion, you could return both domain models and other classes from the Service layer. Some of these classes would be persisted to the database, while others may simply be models used for transferring data in between the layers.
You're explanation is insanely awesome, no one talks about the n-layered architecture like you! they often put their domain models inside the Data Access layer!!! Not like you separated the domain model into a specific layer and made it below the Data Access layer so BAL and DAL both can use it. Thank you, sir.
Very helpful for me. I will start using this method in my future development, it's clear and modern architecture.
In the mean time, there are also videos on a pure clean architecture. You might also want to check that out.
Thank you so much for this video - it really clarified a lot for me. I arrived here out of frustration with my own "Fat Controllers" on a Web App MVC project: I knew my logic should go somewhere else but didn't know where to begin. This is the answer! Really appreciate you sharing your experience.
Thank you for this straightforward, practical and simple course. I'm new in asp and it's helped me to learn Clean and Layer Architecture both for my new project.
did u start your new projects ? im gonna start my project with this Architecture we can discuss
Very useful, I think I am going to have to watch this a few times and then code and example for it to stick. Many Thanks.
Glad it was helpful!
thank you so much, cleared lots of questions from my mind
Great to hear!
Pure gold ! very informative and helpful , Thanks
I'm glad you find this content useful.
Hello Dan, First of all Thank you for the video. I have few questions ,
1) In which layer should DTO Models be used?
2) How do we handle complex JOINS on multiple entities? If we do Joins, should we return IQueryable for GetAll Methods from Repository? ( Case - Db First Approach without Scaffolding )
3) Where are Exceptions thrown? If we use Global Exception Handling, what happens? Is it a good idea to throw exceptions in the Service Layer?
4) Where should Custom Exceptions Classes go?
5) Where should the Request Model Validators Extension be located? (FluentValidation)
Please assist me because I am about to use this Layer for our upcoming project (smaller one)
Please advise if this is a good architecture to use.
Did you find answers for these questions? If so could you pleace provide them because I faced the same problem but can't find anything that would help to solve it
Thank you for your video. First time i'm approaching this kind of information, cuz re-skill from embedded devloper to web developer.
Very good explanation, thank you!
Very good content there ! - thanks for making this
Glad you enjoy my content. Thanks for watching
at 46:11 shouldn't the service layer have dependency on the data access layer too ?
It depends. If you are following 100% clean architecture, then it shouldn't. If you go mostly for a CQRS pattern, then I personally don't see any problem working directly with the DbContext in each handler. That would introduce a dependency, but in this very isolated approach where each action in the application is handled by exactly 1 handler this is not a big problem anymore.
@@Codewrinkles i followed your beginner playlist but in the service layer i had a dependency to the Dal layer because we were accessing Datacontext in ResveationService class ,, is it wrong ? and how i can solve it or is there another way to do it ?
@@mohamedal-qadeery6530 To be honest I don't recall exactly how it was set up during the tutorial and maybe there were some pedagogical reasons why I did that, but usually in the Service you would Inject an IReservationRepository and you would inject the DbContext in the repository. This way, the Service layer would not have a direct dependency on the DAL. It would use just interfaces defined in the domain/core layer.
@@Codewrinkles Thank you so much its clear now :)
in this architecture Where would we put the Dtos? or where ot map it
This is a great tutorial. I really appreciate your effort.
Glad you found it useful
Thanks. Loved the video for every minute . Just curious if can have code access ? Thanks again
Veryuseful, can you help or guide to add Dapper ORM into it
hi good video,
how to insert update the api data into my database where we need to handle it.
do my controller need to access dal layer to save the entities or the service after all the business logic are moved to service
I am very thankful to you, It is very helpful for me. Could we apply Data first approach using Entity framework with PostgreSql DB for same structure?, And it is giving me a circular dependency error. Thanks
Really really good explanation - smart guy!
Glad it was helpful!
Hi - Thank you for a very useful introduction and example of this architecture. I have seen comments elsewhere that the Web or API Layer should not have a dependency on the DAL. Is there any alternative way to Inject the Repository in Startup (or elsewhere) without having an explicit reference to the DAL project?
If your only dependency is in the Startup class or in Program class (if .NET6), then that's totally acceptable by all common sense and best practices. Your dependency is only that you add them to your DI container. An alternative would be using 3rd party DI library and place it in a "common" project, something similar to a shared kernel in DDD terms. But that would be an overhead that would not justify just a compile time dependency. I'm not sure where you have seen or read this, but it's the first time that I can say that it's total nonsense and an advice you should not follow.
Where can we apply identity operations such as adding user permissions and rules?
Can we add it to a reusable repository??
Its connection string, especially in Blazor projects?
Identity operations are for sure part of the domain model. The model classes you need for that belong therefore to the domain layer. The repositories for it belong to the DAL and Idnetity Services belong to the services layer. For Blazor Server there's really no difference. For the client, you should never work with connection strings on the client. Information should be exposed via the API and authentication and authorization will have to follow OpenID Connect and OAuth 2.0 standards.
Thank you so much for this. Very useful
Glad you enjoyed it.
Thank You...
You're welcome
Where should your db context live in this type of project ?
The DbContext should always be where you have your data access logic. Usualy that's a dedicated DAL/persistence project.
Any link for @Dapper ORM.
very helpful, THANKS man
Where should my EF database models go - in the DAL or the Domain?
If you are using dedicated models for EF, then for sure in the data access layer. But usually when we work wit code first we simply re-use our domain models also for EF. As the data access layer will already have a dependency on the domain layer, this should not be any problem.
@@Codewrinkles Hi, what about the EF dbcontext? Inside the models folder of the Domain layer or in the DAL layer? Thanks.
Thank you so much
I have an one doubt, where will be our dbcontext in your scenario? In DAL or in domain?
Definitely DAL.
Great video!
I have been looking into the service layer pattern for a bit. Would you say that this standard layer architecture somewhat adheres to that pattern?
Yes, it's kind of standard. There are a lot of projects out there that run just fine and use services. However, my preference goes towards a more decoupled approach using CQRS,
Great explanation ! thank you .
Glad you liked it
What about in case of reverse engineering. In case of reverse engineering I am not able to create domain and context class in different class libraries. Please give me solution for this.
Sorry, but I don't think I understand your problem. Can you please elaborate and provide a concrete example of what you mean?
Did you find a solution? @@Codewrinkles
Did you find a solution?
Thanks so much, your explanation cleared my confusion of many days. In the case that I need to interact with the file system or email or Sms, where does not functionalities go? Do I create another layer; may be Common Layer or add the functionalities to the Service layer?
Those would be regular services in your service layer. You would have a FileService, an EmailService, an SmsService and so on. No need to create additional projects/layers for that unless your existing project gets overwhelming.
@@Codewrinkles Thanks a lot. Gracias!
thank you! ❤
You're welcome 😊
Is it okay to use multiple classes for Repository? I mean if a domain is too large and have couple of sub-domains, Is that okay to use different implementation of Repository for different sub-domains?
Thank you for the video, i have a question, how i can implement a WeatheropenApi or other external Api to this architecture.
I'm really not sure what you are looking for. On this channel you have a lot of implementations with this pattern. Go to the ASP.NET Core for absolute beginner playlist, and there we implement an API following this architectural pattern. All the playlists that contain live coding sessions implement the different architecture or the other. Why does it need to be a weather API?
Thanks for the video .. now if i want to use a js framework like Angular its going to be in api layer right ?
No, that would be a total different layer that actually doesn''t have to do anything with the API. You can think about this as a totally different application. I know that in the standard VS template for ASP.NET Core with Angular, the API and Angular is kind of in the same project. But that's totally wrong from my point of view because it introduces a lot of misunderstanding.
@@Codewrinkles Thank you for replaying .. yea thats why i got confused
This was very interesting, thank you for explaining. I have a question though, can we use the same architecture with ASP.NET Core Web Application MVC ? I'm trying to build a Web Application and I need it to be well structured.
Sure you can. It really doesn't change anything. You'll just have views and viewmodels on your Presentation layer. But otherwise, nothing changes.
Hi! Shouldn't you use your own models on the web? If you were to use IMapper, where should it be placed? using it on the web, each page/controller will repeat the same logic. Going over that, for POST requests you will directly use the entity from Domain due to the argument of that type from Service. I am facing this problem, I am looking for a way to separate it as clean as possible
In my view, you should never use your domain models as API contracts.
Very informative!
Thank you so much :)
You're welcome. A video on structuring a clean architecture project will also come these days.
@@Codewrinkles love to know that
Thank you sir but can you please move your head on the screen so we can see the other files on the right side bottom. You can just use your voice while doing a tutorial. Great job on the tutorial tho :) thank you
It was very very informative.. 👍 ?As i have heard in the market there are onion, Domain driven , CLEAN architecture but not aware how these works, does this architecture in the video has any name?
It's the standard layered architecture. You can also hear about it under n-layer or n-tier architecture.
@@Codewrinkles Thank u so much for ur quick reply. Loved ur explaination and gonna follow this architecture . 👍
@@sibaprasaddalai3775 My plan is to cover most of the architectures and how we set them up in our VS solution. Hope I'll be able to publish one on clean architecture very soon.
@@Codewrinkles going to subscribe you.... And will be going to follow your each and every video.
Why are you calling interfaces abstractions is that not confusing due to the abstract class type
Both interfaces and abstract classes are abstractions. I think that's something all developers should get accustomed with.
Code you please provide me the source code?
I'm thinking on ways to make the source code available in the near future. Please stay tuned.
In your opinion, in this architecture, would you include Models which are not persisted to the database in your Domain layer as well? For example a WeatherSummary class which had less properties than the WeatherForecast and may be a return type from your Service Layer.
I think that there is a very common misconception that there should be some kind of mapping between what is persisted and what should be in the domain model. When I'm writing my domain, I don't care about persistence. I just care about modeling business behavior. What gets then persisted to the database is a whole different story. So, the answer is, yes, if WeatherSummary is part of business behavior, I would still put it in the domain. But from the name of this suggested class it seems to me that it is more related to the presentation of the data to a consumer and hence I would probably consider placing it in the presentation/API layer as some kind of DTO or ViewModel. My service layer would return the domain objects. The presentation layer is then responsible to aggregate them based on what needs to be shown on the UI or returned from the API.
@@Codewrinkles Thank you for the response, this makes sense. So in your opinion, you could return both domain models and other classes from the Service layer. Some of these classes would be persisted to the database, while others may simply be models used for transferring data in between the layers.