How to use the REPR design pattern in ASP.NET Core

This pattern resolves common issues, like the "swollen controller problem" often found in the MVC (Model-View-Controller) approach, by reducing bloated controllers and adhering to the single responsibility principle.

What is the REPR design pattern?

The REPR design pattern isolates three main concerns: the request, the endpoint logic, and the response. The REPR approach is not tied to any particular architectural style, such as REST or RPC, but can be applied to different API designs to organize the logic more clearly.

Why use the REPR design pattern?

The primary issue with traditional MVC patterns is the creation of bloated controllers, where multiple unrelated methods are placed in a single controller, leading to poor structure and maintainability. The REPR pattern solves this by ensuring each controller is responsible for a single action, aligning with the Single Responsibility Principle (SRP).

The benefits of using REPR include:

• Separation of concerns: Clear distinction between the request handling, business logic, and response formatting.
• Improved maintainability: Cleaner code that is easier to modify and expand.
• Better readability: Well-structured and easily navigable codebase.
• Enhanced testability: Simplified testing since each endpoint is focused on one task.
• Security and scalability: By isolating concerns, security vulnerabilities are minimized, and the application is more scalable.

Key components of the REPR design pattern

• Request: Represents the input data the API expects, used for validation and passing data between layers.
• Endpoint: Handles the logic for processing a request and returning the appropriate response.
• Response: Contains the output data returned to the user, often formatted as JSON or other data formats.

Let’s consider an example of a simple API for managing products.

Request Object:

A class that defines the expected input, such as creating a new product:

public class CreateProductRequest
{
    public int Id { get; set; }
    public string ProductName { get; set; }
    public string Category { get; set; }
    public string Description { get; set; }
    public decimal Quantity { get; set; }
    public decimal Price { get; set; }
}

Endpoint Logic:

In the controller, each endpoint is responsible for a single task.

[Route("api/[controller]")]
[ApiController]
public class CreateProductController : ControllerBase
{
    [HttpPost(Name = "CreateProduct")]
    [ProducesResponseType(StatusCodes.Status204NoContent)]
    public ActionResult CreateProductAsync(CreateProductRequest createProductRequest)
    {
        // Logic for creating product, validation, etc.
        return NoContent();
    }
}

Response Object:

The response class defines the output data format:

public class CreateProductResponse
{
    public int StatusCode { get; set; }
    public string ErrorMessage { get; set; }
}

This class can hold different status codes (like HTTP status codes) to indicate whether the operation was successful or not, and optionally, an error message in case something went wrong.

In the CreateProductController, you would use the CreateProductResponse class to return data to the client after processing the request.

For example, consider a POST endpoint that creates a new product. After validating the input and performing the business logic, you can populate the CreateProductResponse class and return it to the client.

[Route("api/[controller]")]
[ApiController]
public class CreateProductController : ControllerBase
{
    [HttpPost(Name = "CreateProduct")]
    [ProducesResponseType(StatusCodes.Status200OK)]
    [ProducesResponseType(StatusCodes.Status400BadRequest)]
    public ActionResult<CreateProductResponse> CreateProductAsync(CreateProductRequest createProductRequest)
    {
        // Example validation and logic for creating a product
        if (createProductRequest == null || string.IsNullOrEmpty(createProductRequest.ProductName))
        {
            // Return a 400 Bad Request if the input is invalid
            var badRequestResponse = new CreateProductResponse
            {
                StatusCode = 400,
                ErrorMessage = "Invalid product data."
            };
            return BadRequest(badRequestResponse);
        }
        
        // Assuming logic for creating the product is successful
        var successResponse = new CreateProductResponse
        {
            StatusCode = 200, // HTTP Status Code OK
            ErrorMessage = null // No error
        };

        // You could return other details about the product, such as its ID or name, as part of the response
        return Ok(successResponse);
    }
}

In this example:

• If the request is successful (product created), return an HTTP 200 status with the response object containing a StatusCode of 200 and no ErrorMessage.

• If the request is invalid (e.g., missing required fields), return an HTTP 400 status with the response object containing an error message.

If a client calls the CreateProduct endpoint and the request is successful, the JSON response could look like this:

{
    "StatusCode": 200,
    "ErrorMessage": null
}

If the client sends invalid data, the response might look like this:

{
    "StatusCode": 400,
    "ErrorMessage": "Invalid product data."
}

By using the CreateProductResponse class in your endpoint, you separate the concerns of processing the request, handling the business logic, and constructing the response, which improves the maintainability and readability of your API.

Use Cases for the REPR Pattern

The REPR design pattern can be used in various architectures, such as:

• CQRS (Command Query Responsibility Segregation): Separate endpoints for commands (create, update) and queries (get, list).
• Vertical Slice Architecture: Each endpoint is organized in vertical slices based on business functionality.