DEV Community: Martin Staael

Code Review (PRs)

Martin Staael — Tue, 19 Nov 2024 07:06:18 +0000

What is Considered a Good PR Review?

Pull Requests (PRs) are an essential part of collaborative development, ensuring code quality, fostering learning, and maintaining project standards. A good PR review balances technical feedback with a positive, constructive approach that encourages both code improvement and team development.

Goals of a Code Review

Sharing Knowledge: PR reviews enable developers to share domain-specific and technical knowledge, enriching the skill sets of everyone involved.
Spreading Ownership: PRs prevent knowledge silos by encouraging multiple team members to work on different parts of the codebase. This fosters a collaborative environment where the entire team shares responsibility for maintaining the project.
Unifying Development Practices: Every developer has their own style, and PR reviews help standardize coding practices across the team. They promote discussions on architecture, design, and coding styles, creating a cohesive and unified codebase.
Quality Control: PRs ensure early detection of bugs, security flaws, and design issues. They make it easier and cheaper to resolve problems before they make it to production, thus improving the overall quality of the project.

Best Practices for Code Reviews

Decide on a Process: Establish a structured review process that the team follows, including draft states, feedback loops, and final approvals. This process helps streamline PRs and ensure that all aspects of the code are reviewed.
Focus on the Right Things: Prioritize high-impact elements such as functionality, software design, test coverage, and complexity. Automated tools should handle coding styles and formatting, freeing reviewers to focus on the code's quality and architecture.
Discuss the High-Level Approach Early: Before detailed code reviews, ensure that the overall approach and architecture are aligned. This reduces the likelihood of significant rewrites and ensures that the PR aligns with the project's goals.
Optimize for Team Performance: Fast, efficient reviews help the team iterate quickly and minimize context switching. Encourage small, frequent PRs for easier reviews and faster feedback.
Default to Action: Avoid delays in decision-making. If a review is stalled, approve it while flagging areas for future improvement. Keeping momentum is more valuable than achieving a perfect solution on the first try.
Keep Pull Requests Small: Break larger features into smaller, manageable PRs. Smaller changes are easier to review, reducing the chance of introducing defects and making the process more efficient.
Foster a Positive Feedback Culture: Frame feedback around improving the code rather than critiquing the person. Balanced feedback encourages collaboration and helps developers grow without feeling criticized.
Leverage Automation in Reviews: Use tools like Prettier, ESLint, SonarQube, and continuous integration (CI) pipelines to automate style, formatting, and security checks. This reduces the burden on reviewers and allows them to focus on logic and design.
Delegate Nit-Picking to Automation: Use automated tools to enforce consistent code styles, avoiding time spent on subjective preferences. For example, ESLint and Prettier can handle style enforcement, allowing reviewers to focus on substantive issues.
Communicate Explicitly: When providing feedback, be clear about what action is expected from the developer. Explicit communication ensures that changes are made correctly and avoids confusion.
Self-Review Before Submission: Developers should review their own code before submitting a PR, catching small mistakes and improving the quality of the submission. This saves time for reviewers.
Write Clear PR Descriptions: A well-written PR description provides context, explains what has changed, and highlights any special testing instructions. This helps reviewers understand the purpose of the PR quickly and reduces the need for back-and-forth questions.
Use Shared Repository Models: In a collaborative environment, using a shared repository model ensures transparency and facilitates easier reviews. It also helps developers understand the code’s broader context.
Keep Discussions Public: Keep all PR-related discussions in public forums like the PR comments section. This ensures transparency, helps team members who may have missed earlier conversations, and creates a record that can be referenced later.

Conclusion

A good PR review balances technical insight with constructive feedback, promoting both code improvement and team growth. By focusing on essential areas like functionality, design, and testing—and by leveraging automation to handle routine checks—PR reviews can ensure code quality and foster a collaborative, high-performing team environment.

Command Query Responsibility Segregation (CQRS) for High-Performance Applications

Martin Staael — Fri, 11 Oct 2024 03:17:36 +0000

CQRS, or Command Query Responsibility Segregation, is a design pattern that separates read (query) and write (command) operations in an application. This separation allows you to independently optimize how the system handles state-changing commands and data-retrieval queries, improving scalability, performance, and flexibility.

This article will explore how to implement CQRS in .NET 8 using the MediatR library and provide insights into other libraries you can use for similar purposes. Additionally, we'll cover how to integrate middleware into MediatR for pre- and post-processing operations to enhance the pipeline.

Key Benefits of CQRS

Performance Optimization:

By separating commands and queries, each path can be optimized independently. You can use caching or denormalized data for queries, while commands focus on ensuring data consistency and executing business logic.
Scalability:

CQRS allows for independent scaling of the read and write sides of your system. You can horizontally scale reads (queries) across many nodes, while commands (writes) can be scaled separately, ensuring consistency.
Simplified Codebase:

Since commands and queries are separated, each can be designed without affecting the other. This simplifies code and makes the system easier to maintain.
Flexibility in Data Models:

Different data models can be used for reading and writing, allowing denormalized models for fast queries and normalized models for consistency during writes.
Testability:

You can unit test the command and query sides independently, making testing easier and more focused.

Implementing CQRS in .NET 8 with MediatR

MediatR is a lightweight library in .NET that facilitates CQRS by handling commands and queries through request handlers. It promotes clean separation of concerns and decouples the sender of a request from its receiver.

Let’s break down the implementation into commands, queries, and handlers.

1. Command Side: Handling State Changes

Commands in CQRS are responsible for state-changing operations. These include creating, updating, or deleting entities in the system. Commands should encapsulate all the necessary data and business rules to ensure valid state transitions.

Here’s an example of a CreateOrderCommand in .NET 8:

public class CreateOrderCommand : IRequest<Guid>
{
    public string CustomerName { get; }
    public List<OrderItem> Items { get; }

    public CreateOrderCommand(string customerName, List<OrderItem> items)
    {
        CustomerName = customerName;
        Items = items;
    }
}

To handle this command, we’ll create a CreateOrderCommandHandler using MediatR’s IRequestHandler:

public class CreateOrderCommandHandler : IRequestHandler<CreateOrderCommand, Guid>
{
    private readonly IOrderRepository _orderRepository;

    public CreateOrderCommandHandler(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public async Task<Guid> Handle(CreateOrderCommand request, CancellationToken cancellationToken)
    {
        var order = new Order(Guid.NewGuid(), request.CustomerName, request.Items);
        await _orderRepository.SaveAsync(order);
        return order.Id;
    }
}

Here, the CreateOrderCommandHandler processes the command and persists the new order using a repository. The command handler is responsible only for the write logic, keeping it simple and focused.

2. Query Side: Optimizing Data Retrieval

The query side is used to retrieve data. Queries do not modify the state of the system, and you can optimize them for performance by using caching, different data stores, or denormalized data models.

Here’s an example of a query to fetch an order by its ID:

public class GetOrderByIdQuery : IRequest<OrderDto>
{
    public Guid OrderId { get; }

    public GetOrderByIdQuery(Guid orderId)
    {
        OrderId = orderId;
    }
}

A query handler for this query will look like this:

public class GetOrderByIdQueryHandler : IRequestHandler<GetOrderByIdQuery, OrderDto>
{
    private readonly IOrderReadRepository _orderReadRepository;

    public GetOrderByIdQueryHandler(IOrderReadRepository orderReadRepository)
    {
        _orderReadRepository = orderReadRepository;
    }

    public async Task<OrderDto> Handle(GetOrderByIdQuery request, CancellationToken cancellationToken)
    {
        var order = await _orderReadRepository.GetByIdAsync(request.OrderId);
        return new OrderDto
        {
            Id = order.Id,
            CustomerName = order.CustomerName,
            TotalAmount = order.Items.Sum(i => i.Price * i.Quantity)
        };
    }
}

This handler retrieves the data from a read-optimized repository and returns a DTO (Data Transfer Object) that contains only the necessary information for the client.

3. Using MediatR Middleware for Pre- and Post-Processing

MediatR provides support for adding middleware into the request pipeline, allowing you to perform operations before or after a command or query is handled. This is useful for logging, validation, performance monitoring, or modifying requests/responses.

Here’s an example of adding pre- and post-processing behavior with MediatR:

Step 1: Create a Middleware Behavior

public class LoggingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
    private readonly ILogger<LoggingBehavior<TRequest, TResponse>> _logger;

    public LoggingBehavior(ILogger<LoggingBehavior<TRequest, TResponse>> logger)
    {
        _logger = logger;
    }

    public async Task<TResponse> Handle(TRequest request, RequestHandlerDelegate<TResponse> next, CancellationToken cancellationToken)
    {
        _logger.LogInformation($"Handling {typeof(TRequest).Name}");

        // Pre-processing
        var response = await next(); // Call the next handler in the pipeline

        // Post-processing
        _logger.LogInformation($"Handled {typeof(TResponse).Name}");
        return response;
    }
}

Step 2: Register the Middleware

You can register the middleware in your Program.cs or Startup.cs by adding the following:

builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));

This middleware will log the handling of every command and query in your application, providing pre- and post-execution logging.

4. Alternative Libraries for CQRS in .NET 8

While MediatR is widely used, other libraries can be employed for implementing CQRS in .NET 8:

Brighter: Brighter is a command dispatcher and handler library that supports CQRS, including features like outbox pattern and distributed task scheduling. It’s well-suited for more complex systems requiring event sourcing and message dispatching.
SimpleCQRS: A minimalistic library for implementing CQRS in .NET, focused on simplifying the CQRS pattern while providing extensibility for more complex use cases.
FluentValidation: Although not a CQRS library per se, FluentValidation is often used in combination with MediatR for validating commands before they are processed.

Unit Testing CQRS with Xunit and Moq

Unit testing CQRS implementations ensures that both the command and query sides work independently and correctly. Using Xunit and Moq, we can mock dependencies such as repositories to isolate the logic inside command and query handlers. Below, we explore how to test both handlers effectively.

Unit Testing the Command Handler

For the CreateOrderCommandHandler, we want to verify that the command handler saves a new order when a valid command is issued. Using Moq, we mock the IOrderRepository to avoid actual database interactions:

public class CreateOrderCommandHandlerTests
{
    [Fact]
    public async Task Handle_ShouldSaveOrder_WhenCommandIsValid()
    {
        // Arrange
        var mockOrderRepository = new Mock<IOrderRepository>();
        var handler = new CreateOrderCommandHandler(mockOrderRepository.Object);
        var command = new CreateOrderCommand("Test Customer", new List<OrderItem>());

        // Act
        var result = await handler.Handle(command, CancellationToken.None);

        // Assert
        Assert.NotEqual(Guid.Empty, result); // Verify a valid order ID is returned
        mockOrderRepository.Verify(r => r.SaveAsync(It.IsAny<Order>()), Times.Once); // Verify the order was saved once
    }
}

This test checks that the SaveAsync method is called when the command is handled and that a valid Guid is returned.

Unit Testing the Query Handler

For the GetOrderByIdQueryHandler, we need to verify that it returns the correct OrderDto when querying by order ID. Again, we mock the repository to simulate data retrieval:

public class GetOrderByIdQueryHandlerTests
{
    [Fact]
    public async Task Handle_ShouldReturnOrderDto_WhenOrderExists()
    {
        // Arrange
        var mockOrderReadRepository = new Mock<IOrderReadRepository>();
        var orderId = Guid.NewGuid();
        var order = new Order(orderId, "Test Customer", new List<OrderItem>());
        mockOrderReadRepository.Setup(r => r.GetByIdAsync(orderId)).ReturnsAsync(order);

        var handler = new GetOrderByIdQueryHandler(mockOrderReadRepository.Object);
        var query = new GetOrderByIdQuery(orderId);

        // Act
        var result = await handler.Handle(query, CancellationToken.None);

        // Assert
        Assert.Equal(orderId, result.Id); // Ensure correct order ID is returned
        Assert.Equal("Test Customer", result.CustomerName); // Ensure correct customer name
        mockOrderReadRepository.Verify(r => r.GetByIdAsync(orderId), Times.Once); // Verify repository call
    }
}

This test confirms that the query handler returns the expected data and that the repository's GetByIdAsync method is called once.

By using Moq to mock the dependencies, these tests ensure that the business logic for both command and query handlers behaves correctly without requiring real data access.

Summary

CQRS is a powerful architectural pattern that separates the concerns of handling commands and queries, leading to more scalable, maintainable, and performant systems. In .NET 8, MediatR makes implementing CQRS straightforward by handling the separation of requests through command and query handlers.

By integrating middleware, you can further enhance the system by adding pre- and post-processing behaviors, such as logging or validation, into the request pipeline. Additionally, libraries like Brighter or SimpleCQRS offer more advanced CQRS capabilities for distributed systems or event-driven architectures.

Layered Architecture (N-Tier)

Martin Staael — Tue, 08 Oct 2024 14:00:00 +0000

Introduction to Layered Architecture

Layered Architecture, also referred to as N-Tier Architecture, is a design pattern commonly used in software development to structure applications into distinct layers, each responsible for a specific aspect of the system. This pattern provides a clear separation of concerns, making it easier to manage, scale, and maintain the application over time. It’s a traditional and popular approach, especially in enterprise systems, where modularity and maintainability are key requirements.

In this architecture, an application is typically divided into the following layers:

Presentation Layer (UI): Responsible for the user interface and user interaction.
Business Logic Layer: Contains the business rules and application-specific logic.
Data Access Layer: Manages the interaction with databases or other persistent storage.

Each layer communicates with the layers directly above or below it, ensuring a well-organized and maintainable codebase.

With the release of .NET 8, the adoption of Layered Architecture continues to thrive, especially in C# applications designed for enterprise environments. Let’s explore how this architecture can be applied in .NET 8 and the specific advantages it brings to the table.

Key Components of Layered Architecture

1. Presentation Layer

The Presentation Layer is the user-facing part of the application. In .NET 8, this could be built using frameworks like Blazor, ASP.NET Core MVC, or Razor Pages. This layer is responsible for rendering data and handling user interactions. It should not contain business logic but instead rely on the Business Logic Layer to fetch and process data.

A common mistake is mixing UI code with business logic, which makes the application difficult to scale and maintain. By keeping this layer focused on presentation, developers can easily modify the look and feel of the application without affecting the underlying logic.

2. Business Logic Layer

The Business Logic Layer (BLL) is the heart of the application. This is where all the business rules, calculations, and workflows reside. In .NET 8, this layer benefits greatly from features like C# 12, which brings new language improvements, and minimal APIs, making it easier to write clear, maintainable logic. Additionally, the integration of MediatR and CQRS patterns can further simplify complex business workflows.

In this layer, you define how data is processed and transformed before being presented to the user. By isolating this logic, any changes to business requirements can be handled without affecting other parts of the system.

3. Data Access Layer

The Data Access Layer (DAL) is responsible for communicating with the database. This could involve using Entity Framework Core (EF Core), raw SQL queries, or other data access technologies. In .NET 8, EF Core 8 introduces performance improvements and better support for LINQ queries, making it a powerful tool for building this layer.

The DAL should be designed in a way that it only handles data retrieval and persistence, ensuring that business rules and logic stay within the Business Logic Layer. This separation is crucial for achieving a clean and maintainable architecture.

Benefits of Layered Architecture in .NET 8

Separation of Concerns: By dividing the application into layers, each part can focus on a specific responsibility, making it easier to maintain and extend.
Scalability: As each layer operates independently, it's easier to scale different parts of the application as needed. For example, the data layer can be optimized without affecting the business logic or presentation layers.
Testability: Isolating business logic from data access and presentation makes unit testing more straightforward. Developers can test each layer independently, which leads to better code quality and easier debugging.
Maintainability: Layered Architecture ensures that code is organized and easy to navigate. In large enterprise applications, where many developers work on different parts of the system, this clear structure helps avoid confusion and conflicts.
Reusability: Code written in one layer can often be reused across different projects. For instance, the Business Logic Layer can be reused in a mobile or desktop application, with only the Presentation Layer needing adjustments.

Applying Layered Architecture in .NET 8

.NET 8 continues to support and enhance Layered Architecture by providing a robust set of tools and frameworks. Here's a basic approach to implementing this architecture:

Presentation Layer (UI):
- Use ASP.NET Core MVC, Blazor, or Razor Pages to build the user interface.
- Connect with APIs to fetch and display data, with minimal or no business logic embedded in this layer.
Business Logic Layer:
- Use C# 12 features for clean and concise logic implementation.
- Incorporate patterns like MediatR or CQRS to handle business workflows.
- Keep all validation, business rules, and transformation logic in this layer.
Data Access Layer:
- Use EF Core 8 for database interactions or repositories that abstract data storage.
- Ensure that this layer only handles data operations and nothing else.
Dependency Injection (DI):
- Leverage .NET 8's enhanced support for DI to inject dependencies between layers without creating tight coupling.
- Configure services in the Program.cs file to ensure clean and modular code.
Testing:
- Write unit tests for the Business Logic Layer, mocking data access dependencies to verify functionality without requiring a database.
- Integration tests can be written to ensure the entire application flows correctly, testing across layers.

Example: Layered Architecture Implementation in .NET 8

Here’s a code example of a simple layered application, demonstrating how the layers interact.

1. Presentation Layer (ASP.NET Core API)

// Presentation Layer: API Controller
using Microsoft.AspNetCore.Mvc;
using MyApplication.BusinessLogic.Interfaces;
using MyApplication.Models;

namespace MyApplication.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class ProductsController : ControllerBase
    {
        private readonly IProductService _productService;

        public ProductsController(IProductService productService)
        {
            _productService = productService;
        }

        [HttpGet]
        public async Task<IActionResult> GetAllProducts()
        {
            var products = await _productService.GetAllProductsAsync();
            return Ok(products);
        }

        [HttpPost]
        public async Task<IActionResult> AddProduct(Product product)
        {
            await _productService.AddProductAsync(product);
            return CreatedAtAction(nameof(GetAllProducts), new { id = product.Id }, product);
        }
    }
}

2. Business Logic Layer

// Business Logic Layer: Product Service Interface
using MyApplication.Models;

namespace MyApplication.BusinessLogic.Interfaces
{
    public interface IProductService
    {
        Task<IEnumerable<Product>> GetAllProductsAsync();
        Task AddProductAsync(Product product);
    }
}

// Business Logic Layer: Product Service Implementation
using MyApplication.BusinessLogic.Interfaces;
using MyApplication.DataAccess.Interfaces;
using MyApplication.Models;

namespace MyApplication.BusinessLogic.Services
{
    public class ProductService : IProductService
    {
        private readonly IProductRepository _productRepository;

        public ProductService(IProductRepository productRepository)
        {
            _productRepository = productRepository;
        }

        public async Task<IEnumerable<Product>> GetAllProductsAsync()
        {
            return await _productRepository.GetAllProductsAsync();
        }

        public async Task AddProductAsync(Product product)
        {
            if (string.IsNullOrEmpty(product.Name))
                throw new ArgumentException("Product name cannot be empty.");

            await _productRepository.AddProductAsync(product);
        }
    }
}

3. Data Access Layer

// Data Access Layer: Product Repository Interface
using MyApplication.Models;

namespace MyApplication.DataAccess.Interfaces
{
    public interface IProductRepository
    {
        Task<IEnumerable<Product>> GetAllProductsAsync();
        Task AddProductAsync(Product product);
    }
}

// Data Access Layer: Product Repository Implementation
using Microsoft.EntityFrameworkCore;
using MyApplication.DataAccess.Interfaces;
using MyApplication.Models;

namespace MyApplication.DataAccess.Repositories
{
    public class ProductRepository : IProductRepository
    {
        private readonly ApplicationDbContext _context;

        public ProductRepository(ApplicationDbContext context)
        {
            _context = context;
        }

        public async Task<IEnumerable<Product>> GetAllProductsAsync()
        {
            return await _context.Products.ToListAsync();
        }

        public async Task AddProductAsync(Product product)
        {
            await _context.Products.AddAsync(product);
            await _context.SaveChangesAsync();
        }
    }
}

4. DbContext Configuration

// Entity Framework Core DbContext
using Microsoft.EntityFrameworkCore;
using MyApplication.Models;

namespace MyApplication.DataAccess
{
    public class ApplicationDbContext : DbContext
    {
        public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options)
        {
        }

        public DbSet<Product> Products { get; set; }
    }
}

5. Dependency Injection (Program.cs)

using Microsoft.EntityFrameworkCore;
using MyApplication.BusinessLogic.Interfaces;
using MyApplication.BusinessLogic.Services;
using MyApplication.DataAccess;
using MyApplication.DataAccess.Interfaces;
using MyApplication.DataAccess.Repositories;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllers();
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

// Register services and repositories for DI
builder.Services.AddScoped<IProductService, ProductService>();
builder.Services.AddScoped<IProductRepository, ProductRepository>();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.UseHttpsRedirection();
app.UseAuthorization();

app.MapControllers();

app.Run();

Summary

Layered Architecture (N-Tier Architecture) remains a widely used pattern in .NET applications, especially for enterprise systems. By clearly separating the responsibilities of each layer—Presentation, Business Logic, and Data Access—developers ensure that code is modular, maintainable, and scalable.

Clean Architecture

Martin Staael — Sun, 06 Oct 2024 23:20:51 +0000

Introduction

Clean Architecture is a popular software design pattern that enables you to write maintainable, scalable, and testable applications. Introduced by Robert C. Martin (Uncle Bob), this architecture pattern separates your application into layers, making it easier to adapt to changing requirements and technologies. In this article, we'll explore how to implement Clean Architecture in .NET 8.

Why Clean Architecture?

In large applications, code tends to become tightly coupled, making it hard to maintain. Clean Architecture helps by promoting:

Separation of Concerns: Each layer has its own responsibility, reducing coupling.
Testability: Core business logic can be tested independently of external systems (e.g., UI, databases).
Maintainability: Changes in one part of the system (e.g., UI or database) don’t affect other parts.
Flexibility: You can swap external dependencies like databases without affecting business logic.

Core Principles of Clean Architecture

Clean Architecture divides an application into layers with the following key rule: Source code dependencies should point inward, meaning the core business logic should not depend on anything external like a database or web framework.

The main layers are:

Entities (Domain Layer): Core business logic and rules.
Use Cases (Application Layer): Application-specific business rules.
Interface Adapters (Adapters Layer): Adapts external input/output for the application.
Frameworks & Drivers (Infrastructure Layer): External systems like databases, APIs, or UI frameworks.

Let’s walk through each layer with .NET 8 examples.

Layers in Clean Architecture

1. Entities (Domain Layer)

The Entities layer contains the core business logic and models. These are simple objects representing your problem domain. Entities are independent of any external technology or framework, making them reusable across different layers.

// Domain Layer
public class Order
{
    public int Id { get; set; }
    public string CustomerName { get; set; }
    public List<OrderItem> Items { get; set; }

    public decimal GetTotal() => Items.Sum(i => i.Price * i.Quantity);
}

In this example, Order represents a business entity. It contains logic related to the business, like calculating the total price. This logic is independent of external systems like databases or UI frameworks.

2. Use Cases (Application Layer)

The Use Cases layer defines how your application behaves in specific scenarios. Use cases orchestrate interactions between entities but are independent of any external concerns like databases or APIs.

// Application Layer (Use Case)
public class CreateOrderUseCase
{
    private readonly IOrderRepository _orderRepository;

    public CreateOrderUseCase(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public async Task ExecuteAsync(Order order)
    {
        // Business rules validation
        if (order.Items.Count == 0)
            throw new InvalidOperationException("Order must have at least one item.");

        // Save order
        await _orderRepository.SaveAsync(order);
    }
}

The CreateOrderUseCase coordinates the process of creating an order. It interacts with the domain model (Order) and communicates with an external dependency (IOrderRepository). However, it does not know the details of how or where the order is stored.

3. Interface Adapters (Adapters Layer)

The Interface Adapters layer translates data between the core logic and external systems like user interfaces or APIs. In .NET 8, this layer typically includes things like ASP.NET controllers or presenters.

// Interface Adapters Layer
[ApiController]
[Route("api/[controller]")]
public class OrderController : ControllerBase
{
    private readonly CreateOrderUseCase _createOrderUseCase;

    public OrderController(CreateOrderUseCase createOrderUseCase)
    {
        _createOrderUseCase = createOrderUseCase;
    }

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] OrderDto orderDto)
    {
        var order = new Order
        {
            CustomerName = orderDto.CustomerName,
            Items = orderDto.Items.Select(i => new OrderItem
            {
                ProductId = i.ProductId,
                Quantity = i.Quantity,
                Price = i.Price
            }).ToList()
        };

        await _createOrderUseCase.ExecuteAsync(order);
        return Ok();
    }
}

The OrderController adapts the incoming API request into a form that the core application logic (use case) can work with. It handles HTTP requests, processes input data (DTO), and forwards it to the use case. This layer is also responsible for sending responses back to the client.

4. Infrastructure (Frameworks & Drivers Layer)

The Infrastructure layer contains the actual implementation of external dependencies like databases, file systems, and external APIs. In .NET 8, we often use Entity Framework Core to interact with databases.

// Infrastructure Layer (Repository Implementation)
public class SqlOrderRepository : IOrderRepository
{
    private readonly AppDbContext _dbContext;

    public SqlOrderRepository(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task SaveAsync(Order order)
    {
        _dbContext.Orders.Add(order);
        await _dbContext.SaveChangesAsync();
    }
}

Here, SqlOrderRepository is responsible for persisting Order entities to a SQL database using Entity Framework Core. It implements the IOrderRepository interface, which is defined in the core layers, ensuring that the core application logic remains decoupled from the actual database technology.

Dependency Inversion in Clean Architecture

A key principle of Clean Architecture is the Dependency Inversion Principle (DIP). This principle ensures that higher-level modules (like the Application Layer) do not depend on lower-level modules (like database or API implementations). Instead, both depend on abstractions.

In our example, the CreateOrderUseCase depends on the IOrderRepository interface, not on any concrete implementation. This allows us to swap the database implementation (e.g., SQL, NoSQL) without affecting the core application logic.

Setting Up Dependency Injection in .NET 8

In .NET 8, dependency injection (DI) is used to inject dependencies into controllers, use cases, and repositories. Here's how you can register your dependencies in Program.cs:

// Program.cs
var builder = WebApplication.CreateBuilder(args);

// Register use cases
builder.Services.AddScoped<CreateOrderUseCase>();

// Register repositories
builder.Services.AddScoped<IOrderRepository, SqlOrderRepository>();

// Add other services
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

// Build app
var app = builder.Build();

// Configure the HTTP request pipeline
if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

This code registers the CreateOrderUseCase and the SqlOrderRepository as services in the DI container. It also configures the Entity Framework Core DbContext and sets up the HTTP request pipeline.

Putting It All Together

In a Clean Architecture system, each layer has a distinct responsibility, and communication happens only through well-defined interfaces. Let’s see how this all works together:

The user sends an HTTP POST request to create an order.
The controller receives the request and converts the input (DTO) into domain objects.
The controller calls the use case, passing the domain objects.
The use case performs the business logic and interacts with the repository interface.
The repository interface is implemented by the infrastructure layer, where the order is saved to the database.
The result is returned back to the controller, and then to the user.

Each layer remains decoupled from the other layers, allowing the system to be more maintainable and testable.

Testing the Use Cases

One of the major benefits of Clean Architecture is the ease of testing the core application logic without worrying about external dependencies. Here’s an example of how you can unit test the CreateOrderUseCase:

// Unit Test Example
public class CreateOrderUseCaseTests
{
    [Fact]
    public async Task Should_ThrowException_When_OrderHasNoItems()
    {
        // Arrange
        var orderRepository = new Mock<IOrderRepository>();
        var useCase = new CreateOrderUseCase(orderRepository.Object);
        var order = new Order { CustomerName = "John Doe", Items = new List<OrderItem>() };

        // Act & Assert
        await Assert.ThrowsAsync<InvalidOperationException>(() => useCase.ExecuteAsync(order));
    }

    [Fact]
    public async Task Should_SaveOrder_When_OrderIsValid()
    {
        // Arrange
        var orderRepository = new Mock<IOrderRepository>();
        var useCase = new CreateOrderUseCase(orderRepository.Object);
        var order = new Order
        {
            CustomerName = "John Doe",
            Items = new List<OrderItem>
            {
                new OrderItem { ProductId = 1, Quantity = 2, Price = 10 }
            }
        };

        // Act
        await useCase.ExecuteAsync(order);

        // Assert
        orderRepository.Verify(repo => repo.SaveAsync(order), Times.Once);
    }
}

Here, we mock the IOrderRepository interface, allowing us to test the use case in isolation without interacting with a real database.

Summary

Clean Architecture in .NET 8 offers a robust structure that helps to build applications that are scalable

Software Architecture

Martin Staael — Sun, 06 Oct 2024 23:19:08 +0000

Architectural Patterns

When developing software, the architecture you choose plays a critical role in the success, maintainability, and scalability of the application. Architectural patterns are like blueprints that guide the structure of your codebase, helping ensure that your solution is modular, easy to understand, and adaptable to change. In the world of C# development, there are several widely recognized architectural patterns that developers rely on, not just within C#, but across many object-oriented programming (OOP) languages.

In this article, we'll explore some of the most popular architectural patterns in C#, giving a high-level overview of each. As we dive into these, keep in mind that while this article focuses on C#, the principles can often be applied to most OOP languages such as Java, Python, or C++.

1. Clean Architecture

Clean Architecture, introduced by Robert C. Martin (Uncle Bob), is a pattern that encourages separating your code into layers, each with clear responsibilities. The business rules and logic sit at the core of the application, while external dependencies, such as databases or frameworks, are kept at the outer edges. This results in highly maintainable and testable code, with a focus on decoupling the core business logic from the surrounding infrastructure.

2. Layered Architecture (N-Tier)

Layered Architecture, also known as N-Tier Architecture, is one of the most traditional approaches in software development. The application is divided into layers that include:

Presentation (UI)
Business Logic
Data Access Each layer handles specific responsibilities and interacts with the adjacent layers. This model is straightforward and widely used in C# applications, particularly in enterprise environments.

3. Hexagonal Architecture (Ports and Adapters)

Hexagonal Architecture, or Ports and Adapters, emphasizes building applications that are independent of external systems. The core of the application interacts with the outside world (e.g., databases, user interfaces, third-party services) through interfaces (ports), and the actual implementations of these interfaces (adapters) are developed externally. This separation ensures that your business logic is decoupled from the technical details, promoting flexibility and easier testing.

4. CQRS (Command Query Responsibility Segregation)

CQRS stands for Command Query Responsibility Segregation and is a pattern that separates the read (query) and write (command) responsibilities of an application. This pattern is particularly useful in systems with complex domains or where read and write operations have vastly different performance and scaling requirements. While commonly associated with event-driven systems, CQRS can also be employed in more traditional C# applications where performance or scalability is a concern.

5. Microservices Architecture

Microservices Architecture is a modern approach that breaks down an application into a collection of small, autonomous services, each responsible for a specific business function. Each service can be developed, deployed, and scaled independently. In the context of C#, this might involve building multiple APIs or background services that communicate over HTTP or messaging systems like RabbitMQ or Kafka.

6. Event-Driven Architecture

In Event-Driven Architecture, the system's components communicate by producing and consuming events. This architecture is useful for highly distributed systems where components need to respond to state changes in real-time. In C#, you can implement event-driven systems using event sourcing or by leveraging message brokers like Azure Service Bus or Kafka.

7. Domain-Driven Design (DDD)

Domain-Driven Design (DDD) focuses on modeling the core business logic and domain of your application. In DDD, you structure your code around the real-world processes and concepts of the business, often through concepts like Aggregates, Entities, and Value Objects. This results in a codebase that closely mirrors the actual business processes, making the software easier to maintain and evolve as business requirements change.

8. Service-Oriented Architecture (SOA)

Service-Oriented Architecture (SOA) is an older, yet still relevant approach that structures applications as a collection of services, each focused on a specific business capability. In C#, SOA applications often communicate using REST or SOAP protocols. While SOA shares similarities with Microservices, the services in SOA tend to be larger and more interconnected than in a Microservices Architecture.

Summary

Each of these architectural patterns offers a unique approach to structuring your C# applications, with varying levels of complexity, modularity, and flexibility. As a C# developer, understanding these patterns and choosing the right one for your project is key to building scalable and maintainable software.

Over time, I’ll be diving deeper into each architecture with dedicated articles that cover their principles, practical applications, and how to implement them effectively in C#. Stay tuned for detailed explorations of these patterns and their specific use cases in modern software development.