Onion Architecture in ASP - NET Core With CQRS - Detailed PDF

7/26/2020 Onion Architecture In ASP.
NET Core With CQRS - Detailed
U a
Arquitectura de cebolla en ASP.NET núcleo con

CQRS – Detallado
por Mukesh Murugan Actualizado en Jul 26, 2020 ASP.NET Core, Codi cación
En este artículo, hablaremos sobre Onion Architecture In ASP.NET Core y sus ventajas. También construiremos juntos un WebApi que siga
una variante de Onion Architecture para que podamos ver por qué es importante implementar una arquitectura de este tipo en sus
próximos proyectos. Puede encontrar el código fuente de esta implementación en mi GitHub.
Descargo de responsabilidad : Este es un artículo bastante grande con alrededor de 3500+ palabras. Marque esta página y continúe 😀
Tabla de contenidos
1. La necesidad de seguir una arquitectura
1.1. Niveles de Capa Vs
2. Breve descripción general de la arquitectura de capa N
3. Desventajas de la arquitectura de capa N
4. Introducción a la arquitectura de la cebolla
5. Implementación de la arquitectura de la cebolla en ASP.NET proyecto WebApi core
5.1. Con guración de la estructura de la solución
5.2. Adición de Swagger al proyecto WebApi
5.3. Adición de las entidades al proyecto de dominio
5.4. Adición de las interfaces y paquetes necesarios en la capa de aplicación
5.5. Implementación de MediatR para operaciones CRUD
5.6. Con guración de EF Core en el proyecto de persistencia
5.7. Generar las migraciones y la base de datos
5.8. Adición de versiones de API
5.9. Con guración de los controladores
5.10. Pruebas
6. Ventajas de la arquitectura de cebolla en ASP.NET Core
7. Mejoras adicionales
8. Arquitectura limpia con ASP.NET Core WebApi – Plantilla
9. Resumen
La necesidad de seguir una arquitectura

Para mantener la sanidad estructural en soluciones medianas a grandes, siempre se recomienda seguir algún tipo de arquitectura. Debe
haber visto la mayoría de los proyectos de código abierto que tienen varias capas de proyectos dentro de una estructura de carpetas
compleja.
Niveles de Capa Vs
Cuando solo hay una separación lógica en la aplicación, podemos denominarlo como capas o capas N. En los casos en que hay una
separación física y lógica de preocupaciones, a menudo se conoce como aplicación de n niveles donde n es el número de separaciones. 3 es
el valor más común de N. En este artículo, trataremos la Arquitectura en Capas.
Esta capa puede ayudar en la separación de preocupaciones, subdividiendo la solución en unidades más pequeñas para que cada unidad sea
responsable de una tarea especí ca y también para aprovechar la abstracción. Para proyectos de escala media a mayor donde trabajan
varios equipos, las capas tienen ventajas muy obvias bajo las mangas. Permite a un equipo especí co o individuo trabajar en una capa en
particular sin perturbar la integridad de los demás. Hace que sea mucho más fácil realizar un seguimiento de los cambios mediante el control
de código fuente.
Además, sólo hace que toda su solución se vea limpia.
https://www.codewithmukesh.com/blog/onion-architecture-in-aspnet-core/ 1/39
7/26/2020 Onion Architecture In ASP.NET Core With CQRS - Detailed
Antes de entrar en Onion Architecture en ASP.NET Core, primero actualicemos nuestros conocimientos sobre arquitectura de capa N.
Breve descripción general de la arquitectura de capa N

Echemos un vistazo a la arquitectura más popular en ASP.NET aplicaciones principales. Aquí hay una representación diagramatica simple de
una variación de la arquitectura de capa N. La capa de presentación normalmente contiene la parte con la que el usuario puede interactuar,
es decir, WebApi, MVC, Webforms, etc. La lógica de negocios es probablemente la parte más importante de toda esta con guración. Contiene
todas las lógicas relacionadas con el requisito empresarial. Ahora, cada aplicación tiene idealmente su propia base de datos dedicada. Para
acceder a la base de datos, introducimos una capa de acceso a datos. Esta capa normalmente contiene ORM para ASP.NET para
capturar/escribir en la base de datos.
Desventajas de la arquitectura de capa N

Para comprender claramente las ventajas de Onion Architecture en ASP.NET Core Applications, necesitaremos estudiar los problemas con N
Layer Architecture. Es una de las arquitecturas de soluciones de uso común entre los desarrolladores de .NET.
En lugar de construir una estructura altamente desacoplada, a menudo terminamos con varias capas que dependen unas de otras. Esto es
algo realmente malo en la creación de aplicaciones escalables y puede plantear problemas con el crecimiento de la base de código. Para
mantenerlo claro, en el diagrama anterior podemos ver que la capa de presentación depende de la capa de lógicas, que a su vez depende del
acceso a los datos y así sucesivamente.
Por lo tanto, estaríamos creando un montón de acoplamientos innecesarios. ¿Es realmente necesario? En la mayoría de los casos, la capa de
interfaz de usuario (presentación) también se acoplaría a las capas de acceso a datos. Esto derrotaría el propósito de tener una arquitectura
limpia, ¿sí?
En N Layer Architecture, la base de datos suele ser el núcleo de toda la aplicación, es decir, es la única capa que no tiene que depender de
nada más. Cualquier pequeño cambio en la capa Business Logics o en la capa de acceso a datos puede resultar peligroso para la integridad
de toda la aplicación.
Introducción a la arquitectura de la cebolla

The Onion architecture, introduced by Je rey Palermo, overcomes the issues of the layered architecture with great ease. With Onion
Architecture, the game-changer is that the Domain Layer (Entities and Validation Rules that are common to the business case ) is at the Core
of the Entire Application. This means higher exibility and lesser coupling. In this approach, we can see that all the Layers are dependent only
on the Core Layers.
Here is how I would breakdown the structure of the proposed Solution.
Domain and Application Layer will be at the center of the design. We can refer to these layers at the Core Layers. These layers will not
depend on any other layers.
Domain Layer usually contains enterprise logic and entities. Application Layer would have Interfaces and types. The main di erence is that
The Domain Layer will have the types that are common to the entire enterprise, hence can be shared across other solutions as well. But the
Application Layer has Application-speci c types and interface. Understand?
As mentioned earlier, the Core Layers will never depend on any other layer. Therefore what we do is that we create interfaces in the
Application Layer and these interfaces get implemented in the external layers. This is also known and DIP or Dependency Inversion Principle.
For example, If your application want’s to send a mail, We de ne an IMailService in the Application Layer and Implement it outside the Core
Layers. Using DIP, it is easily possible to switch the implementations. This helps build scalable applications.
Presentation Layer is where you would Ideally want to put the Project that the User can Access. This can be a WebApi, Mvc Project, etc.
Infrastructure Layer is a bit more tricky. It is where you would want to add your Infrastructure. Infrastructure can be anything. Maybe an
Entity Framework Core Layer for Accessing the DB, or a Layer speci cally made to generate JWT Tokens for Authentication or even a Hang re
Layer. You will understand more when we start Implementing Onion Architecture in ASP.NET Core WebApi Project.
Implementing Onion Architecture in ASP.NET Core WebApi Project
To keep things simple but demonstrate the architecture to the fullest, we will build an ASP.NET Core Web API that is quite scalable. For this
article, Let’s have a WebApi that has just one entity, Product. We will perform CRUD Operations on it while using the Onion architecture. This
will give you quite a clear picture.
Here is a list of features and tech we will be using for this setup.
Onion Architecture
Entity Framework Core
.NET Core 3.1 Library / .NET Standard 2.1 Library / ASP.NET Core 3.1 WebApi
Swagger
CQRS / Mediator Pattern using MediatR Library
Wrapper Class for Responses
CRUD Operations
Inverted Dependencies
API Versioning
Setting up the Solution Structure

We will start o by creating a Blank Solution on Visual Studio. PS, I use Visual Studio 2019 Comunity which is completely FREE. To install this
IDE, check my article here.
Let’s give it a proper Name.
Under the Blank Solution, add 3 new folders.
Core – will contain the Domain and Application layer Projects

Infrastructure – will include any projects related to the Infrastructure of the ASP.NET Core 3.1 Web Api (Authentication, Persistence etc)
Presentation – The Projects that are linked to the UI or API . In our case, this folder will hold the API Project.
Let’s start adding the required projects. Firstly, under Core Folder Add a new .NET Standard Library and name it Domain.
Why .NET Standard? We know that Domain and Application Project does not depend on any other layers. Also the fact that these projects can
be shared with other solutions if needed (Maybe another solution that is not .NET Core, but .NET Framework 4.7) . Get the point?
A wise person once said – ” Delete the Default Class1 Created by Visual Studio. Always Delete them. “
After creating the Domain project, right click on properties and change the target framework to .NET Standard 2.1 (which is the latest .NET
Standard version at the time of writing this article.)
Similary, create another .NET Standard Library Project in the Core Folder. Name it Application. Do not forget to change the target version here
as well.
Next, let’s go to the Infrastructure Folder and add a layer for Database, (EFCore). This is going to be a .NET Core Library Project. We will name
it Persistence.
Finally, in the Presentation layer, add a new ASP.NET Core 3.1 WebApi Project and name it WebApi.
This is what we will be having right now. You can see the clear seperation of concerns as we have read earlier. Let’s start build up the
architecture now.
Adding Swagger To WebApi Project

Tip #1 – Always use Swagger while working with WebApis. It is so much helpful to have it.
Install the Following packages ot the WebApi Project via Package Manager Console
1. Install-Package Swashbuckle.AspNetCore
2. Install-Package Swashbuckle.AspNetCore.Swagger
We will have to register Swager within the application service container. Navigate to ../Startup.cs and add these lines to the Con gureServices
method.
1. #region Swagger
2. services.AddSwaggerGen(c =>
3. {
4. c.IncludeXmlComments(string.Format(@"{0}\OnionArchitecture.xml", System.AppDomain.CurrentDomain.Base
5. c.SwaggerDoc("v1", new OpenApiInfo
6. {
7. Version = "v1",
8. Title = "OnionArchitecture",
9. });
10.
11. });
12. #endregion
Then, add these lines to the Con gure method.
1. #region Swagger
2. // Enable middleware to serve generated Swagger as a JSON endpoint.
3. app.UseSwagger();
4.
5. // Enable middleware to serve swagger-ui (HTML, JS, CSS, etc.),
6. // specifying the Swagger JSON endpoint.
7. app.UseSwaggerUI(c =>
8. {
9. c.SwaggerEndpoint("/swagger/v1/swagger.json", "OnionArchitecture");
10. });
11. #endregion
Next, we will need to add the XML File (For Swagger Documentaion). To do this, right click the WebApi Project and go to propeties. In the Build
Tab enable the XML Documentation le and give an appropriate le name and location. I have added the xml le to the root of the API
Project.
Make sure that the WebApi Project is selected as the Startup Project. Now Build / Run the Application and navigate to ../swagger. We have got
swagger up and running.
Tip #2 – While running the application, you would see that it navigated to ../weatherforecast by default. This is because of launchSettings.json
settings. In the WebApi Project, Properties drill down, you can nd a launchsettings.json le. This le holds all the con guration required for
the app launch. Change the launch URL to swagger. Thus, swagger will open up by default every time you run the application. This helps you
save some time.
Adding The Entities to the Domain Project

Now, let’s work on the Core Layers starting from the Domain Project. So what is the function of the Domain Layer? It basically has the
models/entities, Exception, validation rules, Settings, and anything that is quite common throughout the solution.
Let’s start by adding a BaseEntity class at Common/BaseEntity.cs in the Domain Project. This abstract class will be used as a base class for our
entities.
1. public abstract class BaseEntity

2. {
3. public int Id { get; set; }
4. }
Now add a Product Class that inherits the Id from the BaseEntity. Create a new class Entities/Product.cs in the Domain Project.
1. public class Product : BaseEntity

2. {
3. public string Name { get; set; }
4. public string Barcode { get; set; }
5. public string Description { get; set; }
6. public decimal Rate { get; set; }
7. }
Adding the Required Interfaces And Packages in Application Layer

As mentioned earlier, the Application Layer will contain the Interfaces and Types that are speci c for this Application.
Firstly, Add Reference to the Domain Project.
Then, install the required packages via Console.
1. Install-Package MediatR.Extensions.Microsoft.DependencyInjection
2. Install-Package Microsoft.EntityFrameworkCore
We have a Entity named Product. Now we need to establish this class as a Table using Entity Framework Core. So we will need a
ApplicationDBContext. But the catch is that, we won’t create the actual concrete implementation of the ApplicationDbContext here in the
Application Layer. Rather, we will just add a IApplicatoinDbContext Interface so that the EF Logics does not fall under the Application Layer,
but goes to the Persistence layer which is outside the core,
This is how you can invert the dependencies to build scalable applications. Now , the advantage is that, tommorow, you need a di erent
implementation of the ApplicationDbContext, you don’t need to touch the existing code base, but just add another Infrastructure layer for
this purpose and implement the IApplicationDbContext. As simple as that.
Create a new folder Interfaces in the Application Project. Add a new interface in it, IApplicationDbContext
1. public interface IApplicationDbContext

2. {
3. DbSet<Product> Products { get; set; }
4. Task<int> SaveChanges();
5. }
This is another variant that i have noticed in many huge solutions. Let’s say you have around 100 interfaces and 100 implementations. Do you
add all this 100 lines of code to the Startup.cs to register them in the container? That would be insane in the maintainability point of view. To
keep things clean, what we can do is, Create a DependencyInjection static Class for every layer of the solution and only add the
corresponding . required services to the corresponding Class.
In this way, we are decentralizing the code lines and keeping our Startup class neat and tidy. Here is an extension method over the
IServiceCollection.
1. public static class DependencyInjection

2. {
3. public static void AddApplication(this IServiceCollection services)
4. {
5. services.AddMediatR(Assembly.GetExecutingAssembly());
6. }
7. }
Here we will just Add Mediator to the service collection. We will implement Mediator pattern later in this tutorial.
And all you have to do in the WebApi’s Startup class in just add one line. This essentially registers all the services associated with the
Application Layer into the container. Quite handy, yeah?
1. services.AddApplication();
Implementing MediatR for CRUD Operations

In Application Layer, Create a New Folder called Features. This will have all the logics related to each Feature / Entity. Under this folder, add a
new one and name it ProductFeatures. Then add a Commands and Queries folder to it.
I have already written a detailed article on MediatR and CQRS pattern in ASP.NET Core 3.1 WebApi Project. You can follow that article and add
the Required Commands and Handlers to the Application Layer.
I will add the links to the source code of each le. Basically these 5 Classes would cover our CRUD Operations implementation. Make sure
that you have gone through my article about CQRS for ASP.NET Core before proceeding.
CreateCommand –
https://github.com/iammukeshm/OnionArchitecture/blob/master/Application/Features/ProductFeatures/Commands/CreateProductCommand.cs
DeleteCommand –
https://github.com/iammukeshm/OnionArchitecture/blob/master/Application/Features/ProductFeatures/Commands/DeleteProductByIdCommand.
UpdateCommand –
https://github.com/iammukeshm/OnionArchitecture/blob/master/Application/Features/ProductFeatures/Commands/UpdateProductCommand.cs
GetAllQuery –
https://github.com/iammukeshm/OnionArchitecture/blob/master/Application/Features/ProductFeatures/Queries/GetAllProductsQuery.cs
GetByIdQuery –
https://github.com/iammukeshm/OnionArchitecture/blob/master/Application/Features/ProductFeatures/Queries/GetProductByIdQuery.cs
So Far So Good?
Stay up to date! Get all the latest & greatest articles / in depth Guides on .NET Core / ASP.NET Core
delivered straight to your inbox. Subscribe now!
Name
Email
Subscribe
Setting Up EF Core on the Persistence Project

Firstly, add a connection string to the appsettings.json found in the WebApi Project.
1. "ConnectionStrings": {
2. "DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=onionDb;Trusted_Connection=True;Multip
3. }
With the CRUD logics out of the ways, let’s setup EFCore in the Persistence Layer and try to generate a database. Install the following
packages to the Persistence Project.
1. Install-Package Microsoft.EntityFrameworkCore
2. Install-Package Microsoft.EntityFrameworkCore.SqlServer
Remember we created an IApplicationDBContext Interface in the Application Layer? This is where we will be implementing it. Create a new
folder named Context and add a new class ApplicationDbContext. This class will implement IApplicationDBContext.
1. public class ApplicationDbContext : DbContext, IApplicationDbContext

2. {
3. public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
4. : base(options)
5. {
6. }
7. public DbSet<Product> Products { get; set; }
8. public async Task<int> SaveChanges()
9. {
10. return await base.SaveChangesAsync();
11. }
12. }
We will have to register IApplicationDBContext and bind it to ApplicationDbContext, right? Similar to the Application layer, we will have to
create a new class just to register the dependencies and services of this layer to the service container.
Add a new static class, DependencyInjection
1. public static class DependencyInjection

2. {
3. public static void AddPersistence(this IServiceCollection services, IConfiguration configuration)
4. {
5. services.AddDbContext<ApplicationDbContext>(options =>
6. options.UseSqlServer(
7. configuration.GetConnectionString("DefaultConnection"),
8. b => b.MigrationsAssembly(typeof(ApplicationDbContext).Assembly.FullName)));
9. services.AddScoped<IApplicationDbContext>(provider => provider.GetService<ApplicationDbContext>(
10. }
11. }
And in the Startup class/ Con gureServices method of the WebApi Just Add the following line. You can now see the advantage of this kind of
approach.
1. services.AddPersistence(Configuration);
Generate the Migrations and the Database

As our ApplicationDbContext is con gured, let’s generate the migrations and ultimately create a Database using Ef Core Tools – Code First
Approach.
Install the following packages in the WebApi Project.
1. Install-Package Microsoft.EntityFrameworkCore.Tools
2. Install-Package Microsoft.EntityFrameworkCore.Design
Now, open up the package manager console and select the Persistence project as the default prject (as mentioned in the sceenshot below.).
This is because the actual ApplicationDBContext is implemented in the Persistence layer, remember?
Then, run the following commands to add migrations and to generate / update the database.
1. add-migration Initial
2. update-database
You will get a ‘Done’ message.
Adding API Versioning

Just to make our solution a bit more clean, let’s also add API Versioning to the WebAPI.
I have written a detailed article on API Versioning in ASP.NET Core 3.1 WebApi. Feel feel to read it to get a complete idea of this concept.
Install the required package.
1. Install-Package Microsoft.AspNetCore.Mvc.Versioning
In the Startup/Con gureServices of the API project, add these lines to register the Versioning.
1. #region API Versioning

2. // Add API Versioning to the Project
3. services.AddApiVersioning(config =>
4. {
5. // Specify the default API Version as 1.0
6. config.DefaultApiVersion = new ApiVersion(1, 0);
7. // If the client hasn't specified the API version in the request, use the default API version number
8. config.AssumeDefaultVersionWhenUnspecified = true;
9. // Advertise the API versions supported for the particular endpoint
10. config.ReportApiVersions = true;
11. });
12. #endregion
Setting up the Controllers

This is the nal step of setting up Onion Architecture In ASP.NET Core. We will have to wire up a controller to the Application Layer.
Create a Base Api Controller. This will be an Empty API Controller which will have Api Versioning enabled in the Attribute and also a MediatR
object. What is aim of this Base Controller? It is just to reduce the lines of code. Say, we add a new controller. We will not have to re-de ne the
API Versioning route nor the Mediatr object. But we will just add the BaseAPI Controller as the base class. Get it? I will show it in
implementation.
Add new Empty API Controller in the Controllers folder and name it BaseApiController.
1. using MediatR;
2. using Microsoft.AspNetCore.Http;
3. using Microsoft.AspNetCore.Mvc;
4. using Microsoft.Extensions.DependencyInjection;
5.
6. namespace WebApi.Controllers
7. {
8. [ApiController]
9. [Route("api/v{version:apiVersion}/[controller]")]
10. public abstract class BaseApiController : ControllerBase
11. {
12. private IMediator _mediator;
13. protected IMediator Mediator => _mediator ??= HttpContext.RequestServices.GetService<IMediator>(
14. }
15. }
You can see that we are adding the API Versioning data to the route attribute and also creating a IMediator object.
Next, let’s create our actual ENtity endpoint. Create a new folder inside the Controllers folder and name it ‘v1’. This means that this folder will
contain all the Version 1 API Controllers. Read more about API Versioning to understand the need for this here.
Inside the v1 Folder, add a new empty API Controller named ProductController. Since this is a very basic controller that calls the mediator
object, I will not go in deep. However, I have previously written a detailed article on CQRS implementation in ASP.NET Core 3.1 API. You could
go through that article which covers the same scenario. Read it here.
1. [ApiVersion("1.0")]
2. public class ProductController : BaseApiController
3. {
4. /// <summary>
5. /// Creates a New Product.
6. /// </summary>
7. /// <param name="command"></param>
8. /// <returns></returns>
9. [HttpPost]
10. public async Task<IActionResult> Create(CreateProductCommand command)
11. {
12. return Ok(await Mediator.Send(command));
13. }
14. /// <summary>
15. /// Gets all Products.
/// /
16. /// </summary>
18. [HttpGet]
19. public async Task<IActionResult> GetAll()
20. {
21. return Ok(await Mediator.Send(new GetAllProductsQuery()));
22. }
23. /// <summary>
24. /// Gets Product Entity by Id.
25. /// </summary>
26. /// <param name="id"></param>
28. [HttpGet("{id}")]
29. public async Task<IActionResult> GetById(int id)
30. {
31. return Ok(await Mediator.Send(new GetProductByIdQuery { Id = id }));
32. }
33. /// <summary>
34. /// Deletes Product Entity based on Id.
35. /// </summary>
38. [HttpDelete("{id}")]
39. public async Task<IActionResult> Delete(int id)
40. {
41. return Ok(await Mediator.Send(new DeleteProductByIdCommand { Id = id }));
42. }
43. /// <summary>
44. /// Updates the Product Entity based on Id.
45. /// </summary>
47. /// <param name="command"></param>
49. [HttpPut("[action]")]
50. public async Task<IActionResult> Update(int id, UpdateProductCommand command)
51. {
52. if (id != command.Id)
53. {
54. return BadRequest();
55. }
56. return Ok(await Mediator.Send(command));
57. }
58. }
That’s quite everything in this simple yet powerful implementation of Onion Architecture in ASP.NET Core. Build the application and let’s test
it.
Since we are already talking about a form of Clean Architecture in ASP.NET Core Applications, it would help if you read about certain tips
to write clean and scalable C# Code. This knowledge will drastically improve the way you start building applications in .NET – Read the
article here (20 Tips to write Clean C# Code)
Testing
Run the application and open up Swagger. We will do a simple test to ensure that our solution works. I will just create a new product and
make a request to query all the existing products as well.
You can see that we receive the expected data.
Advantages of Onion Architecture in ASP.NET Core

The advantages of this designs is as follows.
Highly Testable – Since the Core has no dependencies on anything else, writing automated tests are exible,
Database Independent – Since we have a clean separation of data access, it is quite easy to switch between di erent database providers.
Switchable UI Layer (Presentation) – Since we are keeping all the crucial logics away from the presentation layer, it is quite easy to switch to
another tech – including Blazor.
Much Cleaner Codebase with well structured Projects for better understanding with teams.
Further Improvements
Since this is a very standard implementation of Onion Architecture in ASP.NET Core to make it clear for you guys, I have avoided several
components like Authentication, Exception Handling, Mediator Pipeline Logging, Error Logging, Background Processing, Response Wrappers
to keep the size of the article compact.
However, I have covered few of these topics in other articles in my blog already. You could go through them to understand the core concepts
and to learn how everything works.
Pagination & Response Wrappers

JWT Authentication in API – With Refresh Tokens.
Error Logging with Serilog
Background Job Processing with Hang re
I am planning to build a fully- edged Clean Architecture Solution Template, which you guys can just download and start using for your new
projects in no time. I would like to know your opinion about this. A Standalone WebApi Clean Architecture Solution? MVC Clean Architecture
Solution? Let me know in the comments section below.
Clean Architecture with ASP.NET Core WebApi – Template

Here is a Full Fledged Clean Architecture Solution for ASP.NET Core 3.1 – Open Source – Free for the community . Let’s build the perfect
Starter Template for anyone who get’s started with Clean WebApi Projects! Here is how the Solution Folder Structure Looks like.
If you found this article helpful,
Buy me a coffee
Summary
Fun Fact – Microsoft themselves recommend this kind of architecture for complex solutions. Few of the solutions developed and maintained
by Microsoft MVPs like eShopOnWeb and eShopOnContainers also follow a similar (slightly more complicated variant of this approach).
I hope that this is quite understandable to all, especially the ones starting about with the entire Solution Architecturing Stu . Let me know
your feedback and the scopes of improvement in this approach. You can nd the entire source code on my Github Repository. Feel free to
fork it and make necessary contributions if you feel so 😀 Happy Coding 🙂
16 Shares
 Facebook 0  reddit 0  Twitter 11  LinkedIn 5  Pinterest 0
58 Comments
Victor on June 18, 2020 at 9:41 pm
As promised, you have delivered again Mukesh. Still not completely clear about what goes where but your article has greatly
improved my understanding about this architecture. I also liked that you started with a clean slate as most out there just show
it ready-made and try to explain from there. I am leaning towards the API template as I usually use SPA’s. Overall, awesome
stu .
Reply
Mukesh Murugan on June 18, 2020 at 9:54 pm

Hi Victor, Thanks for the early feedback. Yes, this is quite a lot of details that may be overwhelming initially. I have tried
to make it as simple as possible to understand how the entire architecture is designed. But I guess there is a lot of
room for optimizing the content. I Will work on that as well. However, you could also check the code on my GitHub to
get a detailed understanding.
Thanks and Regards
Reply
Tran Quoc Hoan on June 20, 2020 at 6:08 pm

This post is very clear and easy to understand.
And I am accidently know your website from the Asp.Net Core on Facebook several months ago and still follow
you until now.
You has helped me a lots to improve my Asp.Net skills! I have read a lot of websites on the internet but almost
these a articles are not clearly or hard to understand because they don’t write everything from scrath like you
did!
Keep posting!
Thanks you so much Mukesh!
Reply
Hi. Thanks for your lovely feedback. Hoping to bring in more rich articles.
Thanks and Regards.
Reply
Rob on June 19, 2020 at 1:05 pm

Like with many online examples, your example is missing real life examples. It would been even better when you
implement validation rules, authentication/authorization, etc.
This way developers can really learn how the onion architecture is implemented.
Anyway thanks for e ort, really appreciated.
Reply
Brian on June 20, 2020 at 5:47 pm

YES! What Rob says. There are so many unanswered questions and pitfalls once you start coding. For
beginners it would be extremely bene cial to have real world examples
Reply
Arthur on June 24, 2020 at 9:38 am

https://github.com/gothinkster/aspnetcore-realworld-example-app – this might help you
Reply
Arthur Gorr on July 3, 2020 at 3:32 am

What a pleasure to follow an article with code that works straight away. Now I want to read your other articles as well!
Reply
Mukesh Murugan on July 3, 2020 at 4:25 pm

Hi Arthur, Thanks for the feedback.
I have covered many aspects of ASP.NET Core. Please go through the article list.
Thanks and regards
Reply
Arjunan on June 19, 2020 at 3:03 am

Thala it’s awesome… Keep posting 😀
Reply
Mukesh Murugan on June 19, 2020 at 4:10 am

Thanks for the feedback Arjunan 😀
Reply
Jeeva J on June 19, 2020 at 4:41 am

Good article for Beginners. Keep doing it. All the best.
Reply

Thanks Jeeva
Reply
dimitris papadimitriou on June 20, 2020 at 10:11 am

Nice article, i am writing a guide on how we can use the language-ext functional library in C# with the onion architecture as
seen in the sample application
https://github.com/louthy/language-ext/tree/main/Samples/Contoso
the book is almost done
https://leanpub.com/practical-functional-CSharp
i will send you a copy when i nish it.
Reply
Mukesh Murugan on June 20, 2020 at 10:37 am

Hi. That’s a pretty nice topic. Would love to read to your book.
Thanks & Regards.
Reply
anonymous on June 20, 2020 at 5:36 pm

services.AddPersistence(Con guration);
not working for me, do I need to add project reference to webapi?
If yes, then whats the point of abstraction.
Reply
Kuvondik on June 21, 2020 at 11:02 am

Yes, I think that’s wrong, by theory it should be inside application DI container
Reply

Oops sorry, that’s right you have to add Infrastructure to your WebApi
Reply
Kashif Reza on July 26, 2020 at 6:38 am
yes started with very good notion but ending up few things which is not really great and can be modi ed in next
version of this boilerplate code
* Avoid direct reference of DAL/Persistence layer to Presentation layer

* can introduce AggregateRoot etc
* we can also avoid having reference of EF in application and Presentation layer
Well the notion is Data access layer technology keep changing after almost 3-4 years of life span.
So if tomorrow we want to change EF with any other ORM(like dapper etc) it will impact Persistence, Application and
Presentation layer. which is NOT good.
since we are ending up with CQRS then we may think of adding event-sourcing etc, however event sourcing or event
storing is NOT compulsion to to implement CQRS
Reply
Eslam on June 20, 2020 at 9:21 pm

Thanks Mukesh for your e ort in this great article but when will you write about these topics ‘Authentication, Exception
Handling, Mediator Pipeline Logging, Error Logging, Background Processing, Response Wrappers’
Reply

Hi, Thanks for writing.
Authentication, Response Wrappers, Error Logging and Job Processing is already covered in my other articles.
Here are the links –
https://www.codewithmukesh.com/blog/aspnet-core-api-with-jwt-authentication/ (Auth)
https://www.codewithmukesh.com/blog/hang re-in-aspnet-core-3-1/ (job processing)
https://www.codewithmukesh.com/blog/serilog-in-aspnet-core-3-1/ (error logging)
https://www.codewithmukesh.com/blog/pagination-in-aspnet-core-webapi/ (wrappers & paginations)
I forgot to add the links to this articles. Thanks for reminding me 😀
Regards.
Reply

Firstly, Add Reference to the “Domain” Project.
Then, install the required packages via Console.
Install-Package MediatR.Extensions.Microsoft.DependencyInjection
Install-Package Microsoft.EntityFrameworkCore
—————————————————————————————————-
I think it should be in Application Project, shouldn’t it?
Reply
Ville S on June 21, 2020 at 11:16 am

I’ve been building an application with similar architecture. There should be no reference from Presentation layer to the
Infrastructure layer, where the ApplicationDbContext is. But I have not been able to achieve this in practice. You run database
migrations directly with command update-database from Package Manager Console. But what about in production? I want to
have automatic migrations there when I deploy new version. Natural place would be to run migrations in Startup class (which
is in Presentation layer because it’s application root). I’ve registered my dependency in Infrastrucure layer as you by using
IApplicationDbContext interface (I use Autofac modules but same idea), but when I execute the Migrate method in startup, I
get following error:
Unable to create an object of type ‘ApplicationDbContext’. Add an implementation of ‘IDesignTimeDbContextFactory’ to the

project, or see https://go.microsoft.com/fwlink/?linkid=851728 for additional patterns supported at design time.
The only way around seems that I need to implement IDesignTimeDbContextFactory interface in Presentation layer, and then
I’m forced to have reference to Infrastrucure layer, like this: https://codingblast.com/entityframework-core-
idesigntimedbcontextfactory/
Any advice? How you handle migrations in production?
Reply

Given the fact that ASP.NET Core has DI and Services, it would not make sense to not have a reference between these
layers.
Running migrations / seeding at startup might be a bit of performance bottleneck. You could use the CLI for this.
Sometimes we use SQL scripts as well when required. (There is something called Script migrations in EFCore).
Thanks and Regards
Reply
Alexander Batishchev on June 22, 2020 at 5:10 am

Database migration should be handled by your CI/CD pipeline. Your application code shouldn’t know nor care about
such thing as the database schema version.
This is a infrastructure concern and should be handled by the application infrastructure. It can be a separate repo that
creates external resources (a database is the simplest example) or a tool that lives in the application’s repo but runs
before the application itself.
This way you achieve one of the most important principles: the separation of the application and infrastructure layers.
Which allows while coexist also be developed by separate people and at separate pace.
Reply
Eugene on June 21, 2020 at 5:15 pm

Thanks for the article.
Even though you said application layer doesn’t depend on any other layers, you immediately leak entity Framework and
asp.net core into it by the means of dbset and iservicecollection. This is e ectively the same as leaking infrastructure and
presentation layer into application layer, you’re bound to the technologies and cannot replace them with anything else.
Reply

Hi, Thanks for writing.
Yes, EFCore is installed in the Application layer as well. This approach is under the assumption that we would not
switch away from EFCore for a very long time, which I think would not happen for at least the next 10-15 years. Also,
Application layer is not depending on anything else other than the domain entities.
Reply

Application is the composition root so must know (references) all underlying libraries and explicit
dependencies. You may have some implicit but then the app/cr have no knowledge of them.
You can move the composition logic in a separate project but in most cases it makes no di erence, nor sense.
Adding a layer of abstraction for ORM or cloud provider are the best example of faux abstraction, the one that
add no good but unnecessarily complicates the codebase. it’s also known as the overengineering. There are
special cases when you need (a library to do exactly that) but again in most cases it makes no sense.
Reply

You may want to sort usings in a way that System will go on top. You can con gure VS accordingly.
Also validation clutters the code of controllers, should be moved to a separate class (because of OOP+SRP which are the
foundational principles behind CQRS).
Reply

Yes, Fluent Validations are great for this purpose.
Reply
Zahid Saleem on June 22, 2020 at 10:08 am

Hi, Thanks for the article and you are doing great e ort, please keep it up.
In Persistence layer SaveChanges() should not be override method?
Reply

Hi, Thanks!
SaveChanges depends on you actually. This is just a demonstration. You could use SaveChangesAsync as well, to keep
the existing savechange();
Reply
Randal on July 17, 2020 at 3:49 pm

Hi Mukesh, thank you for this great article.
I am reading this on an Ipad pro (1024×1366) and there is a horizontal scrollbar that is a bit annoying when I
scroll vertically.
Issue seems like the deeply nested comments.
Hope you can take a look at it.
Reply

Hi, Thanks for the feedback.
I am sorry for the experience. Will give it a look. Thanks for letting me know.
Regards.
Reply
Ryan Marcotte on June 22, 2020 at 10:43 pm

I had been working on a similar .NET Core onion architecture example for my team as well, so I’ve forwarded this article to
them while I nish up my own example. I anticipate the setup walkthrough being more helpful than my sequence of PRs they
would be viewing. Thanks for the writeup!
I forwarded the article with the following caveats though…

– Anemic domain models are an anti-pattern (https://martinfowler.com/bliki/AnemicDomainModel.html). The Product class,
being part of the Domain project, falls squarely in this category. Primitive obsession is also a problem (see
https://blog.ploeh.dk/2011/05/25/DesignSmellPrimitiveObsession/). The Product class is being used for both in-memory
processing and for persistence, a clear violation of the single responsibility principle. Pluralsight has a great course on moving
o the anti-pattern: https://www.pluralsight.com/courses/refactoring-anemic-domain-model
– As someone else already mentioned, the IApplicationDbContext interface couples consuming components to the use of EF
Core (because DbSet is a public property eld). Introducing DDD repositories that hide EF Core entirely would be preferred.
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-
persistence-layer-design has more details.
– Since MediatR is already being used to encapsulate system commands, one could instead implement the “unit of work”
pattern as a generic pipeline behavior rather than requiring developers to inject IApplicationDbContext and call SaveChanges
explicitly for every request handler. https://github.com/kgrzybek/modular-monolith-with-ddd#36-cross-cutting-concerns has
some relevant details (in addition to being a high-quality comprehensive .NET Core onion/CQRS/DDD example).
Again, I appreciate the writeup! It just has a few less-than-ideal architecture choices (for long-lived solutions) that prevent me
from recommending it as-is. I’m happy to answer any questions.
Reply

Hi. Thanks for the feedback. Firstly, this is just a basic level implementation for the beginners. Did not want it to be
much complex.
1. Yes, Automapper and DTO classes will be used.
2. Isnt Repositories a bad idea to go along with EFCore? and more redundant code?
Thanks for sharing, and I am currently working on a full edged Clean Architecture for WebApi.
Regards
Reply
Ryan Marcotte on June 23, 2020 at 7:49 pm

Could you give an example of why you might think repositories are a bad idea alongside EF Core and why they
would introduce redundant code?
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-
patterns/infrastructure-persistence-layer-implemenation-entity-framework-core has some information about
this… Is there anything in that document related to your concern?
Reply

Given the fact that EFCORE is already built on Repository pattern and UOW, do you really need another
layer of abstraction layer over it using a IREPO? I really don’t see any advantage of such an approach
here. Also, as the application scales up, doesn’t your repo count grow too unnecessarily? Please correct
me if I am wrong
Reply
Ryan Marcotte on June 26, 2020 at 12:11 am

The answer is, as always, “it depends”, but I would argue the extra abstraction layer is de nitely
worth the e ort for projects of su cient size and scope.
As currently written, your request handler implementations depend on **the entire

database**. That is what IApplicationDbContext is; presumably, you will be exposing all tables
with this object. For a simple project, this may be ne. However, as your project increases in
size and scope, that particular architecture choice will enable database-level entanglements
that make it incredibly di cult to refactor and decompose the solution (into modules and/or
microservices) down the road. I recommend the book Monolith to Microservices by Sam
Newman for some insights on this topic.
“The entire database” is not an abstraction. It’s too low-level. Interestingly, per your own
admission, “EFCORE is already built on Repository pattern and UOW” and so why have
IApplicationDbContext at all if all it does is expose EFCore classes (DbSet) and functions? YAGNI.
Implementing your own repositories (one per aggregate root) as an abstraction layer over top
of EF Core has multiple bene ts:
– your domain layer can de ne the repository interface, while the implementation of the
repository goes in the infrastructure layer; this is onion architecture in action! (depend on
abstractions, not implementations)
– per DDD, request handlers are analogous to system commands, and system commands are
part of your domain layer; your current implementation violates DDD onion architecture
because your request handlers depend directly on EFCore (via IApplicationDbContext)
– repositories expose the precise, limited set of database operations required to service your
domain; this makes your code **simpler** because you have de ned your own API over the
raw database and your request handlers will use this API
– per the previous point, database-related complexity is con ned to the repositories: the
repository takes care of loading and mapping everything needed to construct the aggregate
root in memory; with your current implementation, this complexity will go in your request
handlers, which should be concerned with domain logic only
– per the previous two points, repositories are useful and reusable (they bundle reusable
pieces of database functionality)
Elsewhere you had mentioned that adding repositories increases lines of code and yes, it does;
however, “number of lines of code” is useless as a quality metric. Coupling between
components and between layers is a much better quality heuristic, and onion architecture is all
about managing that coupling.

Great. This actually cleared a lot of Architecture doubts for me. Thanks! So, in the
implementation of the Repository, is it better to use the concrete class ApplicationDbContext?
or go with IApplicationDbContext? So with this approach, we no longer are bound to just
EFCore. Else, is there any major issue that you see with this implementation. PS, apart from the
usage of Automapper / DTO Classes
Thanks and Regards
Ryan Marcotte on June 27, 2020 at 12:09 am

It is ne for the repository implementations to be directly coupled to EFCore (i.e. use
ApplicationDbContext directly). While the repository **abstraction** is part of your domain
layer, the **implementation** of the repository abstraction is an infrastructure concern and

resides on the outermost layer of the onion. Your application’s composition root (which has
knowledge of all components used in your system) is responsible for associating that
repository abstraction with its implementation. Your request handlers will not know about the
implementation of the repository at all (provided your repository abstraction does not leak
implementation details).
You can nd an example of this at https://github.com/kgrzybek/modular-monolith-with-

ddd/blob/master/src/Modules/Meetings/Domain/Meetings/IMeetingGroupRepository.cs
(abstraction in domain layer) and https://github.com/kgrzybek/modular-monolith-with-
ddd/blob/master/src/Modules/Meetings/Infrastructure/Domain/Meetings/MeetingRepository.cs
(implementation in infrastructure layer). I highly encourage you to check out that GitHub repo
for more high-quality examples of DDD onion architecture in action. It certainly upped my
game!
Fred Bloggs on June 23, 2020 at 12:13 pm

There is no essential di erence between n-tier, onion, hexagonal, layered etc architectures. If you were to cut from the
outside to the centre of your onion diagram, then bend the edges upwards, you’d have the same diagram as for n-tier, for
example.
You mention that n-tier layers are tightly coupled, but that is not actually a requirement! They may be, but that’s just poor
design. It remains poor design no matter which architecture you think you’re using. It is equally possible to do “onion
architecture” badly and tightly couple everything.
These days we have a di erent idea of what should go in a layer than 30 years ago, and we are more careful about where we
put domain logic, presentation logic, and so on. But the architectural principles are all essentially the same.
Layers should not depend too tightly on each other (and should only have any dependency one way, and one layer deep). But
that always applies.
The details always matter here. All these architectures are basically saying you should split up your code into separate areas
of concern, and all the normal rules about dependencies and coupling always apply, redardless. If you put your code in the
wrong layer, or couple things that shouldn’t be coupled, or whatever, none of the architectures will be successful.
Moreover, I think you have made several mistakes in your example.
Using solution folders in Visual Studio is bad. They are are horrible mistake made by Microsoft, and should never be used.
Using di erent projects for di erent layers is only ever coincidentally a good idea. You’d have to have a very large project
before doing that made any sense, in which case moving the application into a more service-based architecture might well be
a better choice.
You should use di erent projects when you need di erent deliverables. Layers do not necessarily need to be in di erent
projects, especially in small applications.
And it is still extremely disappointing that people refuse to work in a test-driven way, and examples like this ignore testing
altogether.
Reply
Daniel on June 23, 2020 at 5:53 pm

Hi Mukesh,
This is a very nice introductory article to some important concepts, and you deserve props for contributing to the community.
However, I wanted to correct a terminology issue. It’s relatively minor, but could lead to confusion for some people down the
road.
You are using CQS (Command Query Seperation), not CQRS (Command Query Responsibility Segregation).
Command Query Seperation splits commands and queries into di erent request types, where commands alter state and may
introduce side e ects, while queries are read-only and side-e ect free. The two types of requests can/do share a common
model and data store. This is an application level pattern to clarify intent.
Command Query Responsibility Segregation is the use of two completely separate models, and often di erent data stores,
where the query store is generally optimized for read e ciency, while the command store is optimized for processing
changes. For instance, your Commands may use a service bus or Event Sourcing to send changes on for further processing,
while your Queries may use compiled SQL views for querying.
CQS also tends to imply immediate consistency between the read and write models, while CQRS often implies eventual
consistency between the read and write models.
Anyway, I suspect you know much or all of this, but I thought it worth addressing so nobody gets confused.
Thanks again
Reply
Jacob on June 24, 2020 at 7:29 am

Hi. Nice and clean article. I have one question though: are you using the IDbContext for a speci c reason? Do you prefer this
instead of the Repository pattern? Normally I use repositories because I can work without any EF reference in my domain /
application layer but having a DbContext can be handy when using things like .Include(). Just wondering 🙂
Reply

Thanks for your feedback!
This is quite a debated question over at the community. This is how I look at it. EFCore is a well-matured variant of EF.
EFCore implements Repository Pattern and UOW already, as stated by Microsoft. In most of the cases, I fail to see the
advantage of having another repository layer over it. Get it? Why have another abstraction of Repository, when it is
already done within EFCore? Also, with this approach, doesn’t the Lines of code increase? I may be wrong but haven’t
come across a use-case where I really need a repo class. What do you think about this?
Reply
Jacob on June 26, 2020 at 12:53 pm

Good point. Maybe I try to hard not to get any implementation details in the Application/Domain layer. It
makes it harder in some cases. I have swapped EF Core for Dapper (but only once) which was fairly easy
because of the repos though. Gonna think about it, thanks!
Reply
Wessam Yaacob on June 24, 2020 at 3:58 pm

Hi ,
Thanks for the perfect explanation. I just’ve a question , In case of integrating with other component , let’s say twilio service ,
so in this case I should Add the interfaces with the desired twilio functionality i want to use, in the application layer then
create new project under infrastructure folder ex: XYZ.Infrastructure.Twilio then add the implementation there , correct me if
I’m wrong 🙂
Reply

Hi, Thanks for the Feedback.
Yes. It actually depends on the use case as well.
1. You could either merge services like Twilio into a single Project layer and implement the interface within each
corresponding folder. eg. Infrastruction.Communication / Twilio. This is if you think the infrastructure implementation
is not very complex.
2. In other cases, like you have mentioned, go with Infrastructure.Twilio. This is if you want a really good separation of
the implementations, as each Project will be generating a DLL.
Thanks and Regards.
Reply
Wessam Yaacob on June 24, 2020 at 6:58 pm

While this architecture is clean enough and as Mukesh said , EFCore already implements Repository Pattern , but still there is
some cases you can introduce new Repository layer ,
1- If you want to hide the implementation of your ORM ( EF ) and you have some assumtions that you would change your
ORM later ( which is not the case most of the time)
2-if you want to limit access to some of your entities you can Introduce a new empty inteface called IAggregateroot then make
your IRepository inherit from IAggregateRoot then set your entites which is accessable every where to implement
IAggregateRoot except the one you don’t want anyone to access it directlty so in this case when you try to inject IRepository
where T : IAggregateRoot it will work only with the accessable entities , ex : you have order & orderItem and you only restrict
access to order entites and any change to orderItem can be done through order 🙂
Reply
Mohsin on June 24, 2020 at 7:38 pm

Hi Mukesh
Thanks for this great article,I am agree that you are saying you are going to build boilerplate that any one can download and
can start working.
Just some question in my mind,thought you can give clear answer on them,because i was working on CQRS but the project
was microservice and is very big.
So can we use CQRS with small projects or it can work good with only big one.
Reply

Hi Mohsin, Thanks for the feedback.
CQRS is something that makes you controllers THIN. It is always a good practise to follow a well-de ned architecture
for every solution. CQRS with MediatR has quite a lot of advantages like the Pipeline Behaviours and Logging.
Answering to your question, It completely depends upon you. If the projects are too small and there is no scope of
scalability in the game, you would not even ideally need an architecture. But if there is a chance of requirement
changes and additional features / infrastructure, it’s better to use CQRS for future proo ng you applications. Also,
CQRS makes your application much more readable and maintainable. What do you think about this?
From my experience, once you start getting comfortable with CQRS, it’s really tough to avoid using it 😀
Thanks and Regards
Reply
Kris-I on July 1, 2020 at 9:02 pm

Hello,
Thanks for this great article. I suppose I can’t use UnitOfWork pattern and generic repo even with Onion architecture. Could
you con rm (or not)
thanks,
Reply

Hi, Thanks for the feedback!
Yes, you can de nitely use Repository Pattern alongside Onion Architecture. It gives a better separation between your
actual database of choice and your data access code. It depends on how organized you want your project to be and
how comfortable you are with the patterns.
Thanks and Regrds
Reply
Kris-I on July 1, 2020 at 9:03 pm

Sorry I wanted to say “can” and not “can’t”
Reply
Kirill on July 10, 2020 at 12:48 pm

Thanks for this article. I am relatively new to building large programs, I am only 17 years old. For a long time I was looking for
material where it will be possible to learn trending technologies in building web applications, and your article is the beginning
for me. Thanks again
Reply
josep temprano on July 21, 2020 at 10:34 am

Good job Mukesh!
Do you have in mind publish another release of the Full Fledged Clean Architecture Solution for ASP.NET Core 3.1 soon?
I am very interested and I need the authorization, authentication and seedind DB parts.
Thanks again for your valuable work.
Josep
Reply

Hi, Thanks a lot for the feedback! Hope you liked the article.
Yes, As a matter of fact I am already building a Solution for Clean Architecture in ASP.NET Core 3.1 WebApi. It’s like
70% done I would say.
You can take a look at the repository here – https://github.com/iammukeshm/CleanArchitecture.WebApi
I am planning to release it in a couple of weeks in a well documented way / One-Click Install Template for Visual Studio
2019.
Thanks and regards.
Reply
josep temprano on July 23, 2020 at 10:47 am

OK, thanks for your reply…waiting for the template! ;-)))
Reply
Trackbacks/Pingbacks
1. The Morning Brew - Chris Alcock » The Morning Brew #3020 - […] Onion Architecture In ASP.NET Core With CQRS – Detailed – Mukesh
Murugan […]
Suscríbete a mi newsletter
Unirse a mi lista de correo para recibir noti caciones sobre mis últimos artículos, tutoriales y guías para principiantes en .NET Stack con C- y cualquier otra
cosa con la que pueda relacionarse como desarrollador.
Nombre
Correo electrónico
subscribir
CATEGORÍAS
.NET Core
Api
ASP.NET Core
ASP.NET Core Security
Blazor
Codi cación
Patrones de diseño
Núcleo de Entity Framework
ETIQUETAS
.NET Core Api asp.net núcleo Estructura del proyecto Blazor C# Cqrs Ide Mediador Serilog Registro estructurado Visual Studio
SEGUIR CODEWITHMUKESH
   
¡APOYENME!
Cómprame un café
Related Articles
JQuery Datatable in ASP.NET Core – Server-Side Processing

by Mukesh Murugan | Updated on Jul 25, 2020
In this article, we will learn how to use JQuery Datatable in ASP.NET Core with Server Side Processing. We will also...
READ MORE
Microservice Architecture in ASP.NET Core with API Gateway

Let's go through a popular way of Building Applications - Microservice Architecture in ASP.NET Core. In this detailed...
READ MORE
Dapper in ASP.NET Core with Repository Pattern – Detailed

In this article, we will learn all about Dapper in ASP.NET Core and make a small implementation to understand how it...
READ MORE
Like my Work?
Join my mailing list to be noti ed about my latest Articles, Tutorials, and Beginner's Guides on .NET Stack using
C# and anything else that you may relate to as a developer.
Name
Email
Subscribe
© codewithmukesh.com 2020 – All rights reserved.

Onion Architecture in ASP - NET Core With CQRS - Detailed PDF

Cargado por

Copyright:

Formatos disponibles

Onion Architecture in ASP - NET Core With CQRS - Detailed PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Onion Architecture in ASP - NET Core With CQRS - Detailed PDF

Cargado por

Copyright:

Formatos disponibles

7/26/2020 Onion Architecture In ASP.

NET Core With CQRS - Detailed

Arquitectura de cebolla en ASP.NET núcleo con

La necesidad de seguir una arquitectura

Además, sólo hace que toda su solución se vea limpia.

Breve descripción general de la arquitectura de capa N

Desventajas de la arquitectura de capa N

Introducción a la arquitectura de la cebolla

Here is how I would breakdown the structure of the proposed Solution.

Implementing Onion Architecture in ASP.NET Core WebApi Project

Setting up the Solution Structure

Let’s give it a proper Name.

Under the Blank Solution, add 3 new folders.

Core – will contain the Domain and Application layer Projects

Adding Swagger To WebApi Project

Then, add these lines to the Con gure method.

Adding The Entities to the Domain Project

1. public abstract class BaseEntity

1. public class Product : BaseEntity

Adding the Required Interfaces And Packages in Application Layer

Firstly, Add Reference to the Domain Project.

Then, install the required packages via Console.

1. public interface IApplicationDbContext

1. public static class DependencyInjection

Implementing MediatR for CRUD Operations

Setting Up EF Core on the Persistence Project

1. public class ApplicationDbContext : DbContext, IApplicationDbContext

Add a new static class, DependencyInjection

1. public static class DependencyInjection

Generate the Migrations and the Database

Install the following packages in the WebApi Project.

You will get a ‘Done’ message.

Adding API Versioning

Install the required package.

1. #region API Versioning

Setting up the Controllers

You can see that we receive the expected data.

Advantages of Onion Architecture in ASP.NET Core

to keep the size of the article compact.

Pagination & Response Wrappers

Clean Architecture with ASP.NET Core WebApi – Template

If you found this article helpful,

 Facebook 0  reddit 0  Twitter 11  LinkedIn 5  Pinterest 0

Mukesh Murugan on June 18, 2020 at 9:54 pm

Thanks and Regards

Tran Quoc Hoan on June 20, 2020 at 6:08 pm

Thanks you so much Mukesh!

Mukesh Murugan on June 20, 2020 at 7:16 pm

Rob on June 19, 2020 at 1:05 pm

Anyway thanks for e ort, really appreciated.

Brian on June 20, 2020 at 5:47 pm

Arthur on June 24, 2020 at 9:38 am

Arthur Gorr on July 3, 2020 at 3:32 am

Mukesh Murugan on July 3, 2020 at 4:25 pm

Arjunan on June 19, 2020 at 3:03 am

Mukesh Murugan on June 19, 2020 at 4:10 am

Jeeva J on June 19, 2020 at 4:41 am

Mukesh Murugan on June 19, 2020 at 12:48 pm

dimitris papadimitriou on June 20, 2020 at 10:11 am

layer, the implementation of the repository abstraction is an infrastructure concern and