DEV Community: Jiten Shahani

API Project Architecture

Jiten Shahani — Mon, 26 May 2025 14:01:36 +0000

This document outlines the structured development of an API designed to efficiently manage fundamental business entities through standardized CRUD (Create, Read, Update, Delete) operations. This API serves as a robust interface for handling Products, Categories, Customers, and Suppliers, ensuring seamless interaction with the underlying database.

Each entity plays a vital role within the application, necessitating well-defined data models and endpoints to facilitate operations such as record creation, retrieval, modification, and deletion.

Project Structure

To ensure modularity, maintainability, and scalability, the API project should be organized into well-defined folders, each serving a distinct purpose:

Entities/               # Models representing database entities, with properties mapped to table columns
DTOs/                   # Data Transfer Objects for request/response handling
Repositories/           # Data access logic, separated from business logic
Services/               # Business logic, managing interactions between repositories and controllers
Controllers/Endpoints/  # API endpoints for handling HTTP requests and responses
Validators/             # Validation logic, ensuring data integrity before processing requests
Middleware/             # Logic that processes requests/responses at various pipeline stages (e.g., authentication, logging)

Entity Classes

The Entities folder should encapsulate classes representing each key entity in the database, defining properties that correspond to table columns. The DeletedOn and DeletedBy columns are included to facilitate filtering of deleted records, as the records are retained in the database rather than being permanently removed.

Example

public class Product
{
    public Guid Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Description { get; set; } = string.Empty;
    public int Quantity { get; set; }
    public decimal Price { get; set; }
    public DateTime CreatedOn { get; set; }
    public string CreatedBy { get; set; } = string.Empty;
    public DateTime? DeletedOn { get; set; }
    public string? DeletedBy { get; set; }
}

public class Customer
{
    public Guid Id { get; set; }
    public string CompanyName { get; set; } = string.Empty;
    public string ContactName { get; set; } = string.Empty;
    public string ContactTitle { get; set; } = string.Empty;
    public string Address { get; set; } = string.Empty;
    public string? Region { get; set; } = string.Empty;
    public string PostalCode { get; set; } = string.Empty;
    public string Country { get; set; } = string.Empty;
    public string Phone { get; set; } = string.Empty;
    public string? Fax { get; set; } = string.Empty;
    public DateTime CreatedOn { get; set; }
    public string CreatedBy { get; set; } = string.Empty;
    public DateTime? DeletedOn { get; set; }
    public string? DeletedBy { get; set; }
}

Utilizing a Base Entity Class

Since multiple entities share common properties such as CreatedOn, CreatedBy, DeletedOn, and DeletedBy, it is advisable to define a base entity class that serves as a foundational structure for inheritance.

Base Entity Class Example

public abstract class BaseDomain
{
    public DateTime CreatedOn { get; set; }
    public string CreatedBy { get; set; } = string.Empty;
    public DateTime? DeletedOn { get; set; }
    public string? DeletedBy { get; set; } = string.Empty;
}

By inheriting from BaseDomain, entities can reuse shared properties, enhancing consistency and reducing redundancy.

public class Product : BaseDomain
{
    public Guid Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Description { get; set; } = string.Empty;
    public int Quantity { get; set; }
    public decimal Price { get; set; }
}

public class Customer : BaseDomain
{
    public Guid Id { get; set; }
    public string CompanyName { get; set; } = string.Empty;
    public string ContactName { get; set; } = string.Empty;
    public string ContactTitle { get; set; } = string.Empty;
    public string Address { get; set; } = string.Empty;
    public string? Region { get; set; } = string.Empty;
    public string PostalCode { get; set; } = string.Empty;
    public string Country { get; set; } = string.Empty;
    public string Phone { get; set; } = string.Empty;
    public string? Fax { get; set; } = string.Empty;
}

DbContext Example

Entity classes serve as the foundation for table creation within Entity Framework, facilitating seamless mapping between code and database structures.

public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    public DbSet<Category> Categories { get; set; }
    public DbSet<Customer> Customers { get; set; }
    public DbSet<Supplier> Suppliers { get; set; }
}

Structuring DTO's

What is a DTO?

A Data Transfer Object (DTO) is a simple object used to transfer data between layers of an application. DTOs help keep your API contracts clean and separate from your database models, ensuring that only the necessary data is exposed to clients and that internal implementation details remain hidden.

The API project should feature a DTOs folder designated for defining Data Transfer Objects (DTOs), which facilitate structured data exchange between clients and the server. Common examples of naming DTOs are CreateProductRequest, UpdateProductRequest, ProductResponse, etc. Each is tailored to meet distinct data processing needs within the API.

Best Practices:

Declare DTO classes as sealed to prevent inheritance.
Avoid third-party NuGet packages for automatic mapping from entities to DTOs and vice versa. Prefer manual mapping for greater control.
Utilize data annotation attributes for validation if required.

Rules for Defining DTO's

When designing DTOs, adhere to the following principles:

DTOs must not contain logic or behavior.
DTOs should not enforce encapsulation. Private or protected members are unnecessary.
Properties (not fields) must be used for serialization compatibility.
Use DTO in naming only when necessary. Prefer meaningful names based on usage.
Mark DTO classes/records as sealed when inheritance is not required.
DTOs are best suited for:
- API Request or Response objects.
- Messaging (Commands, Events, Queries, etc.).

DTO Examples

public sealed class CreateProductRequest
{
    public string Name { get; set; } = string.Empty;
    public string Description { get; set; } = string.Empty;
    public int Quantity { get; set; }
    public decimal Price { get; set; }
}

public sealed class UpdateProductRequest
{
    public Guid Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Description { get; set; } = string.Empty;
    public int Quantity { get; set; }
    public decimal Price { get; set; }
}

public sealed class ProductResponse
{
    public Guid Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Description { get; set; } = string.Empty;
    public int Quantity { get; set; }
    public decimal Price { get; set; }
}

DTO Validation

Ensuring data integrity is a crucial aspect of API development. Proper validation mechanisms help prevent erroneous or malicious data from entering the system, improving reliability and security. Below are some recommended validation approaches for handling API requests effectively.

Built-in Validation (Validator.TryValidateObject)

The .NET framework provides built-in validation capabilities through data annotation attributes, which can be processed using the Validator.TryValidateObject() method. This approach allows developers to validate DTOs by checking for constraints such as required fields, length restrictions, and format enforcement.

Example...

public class CreateProductRequest
{
    [Required]
    [StringLength (100)]
    public string Name { get; set; } = string.Empty;

    [StringLength (500)]
    public string Description { get; set; } = string.Empty;

    [Range (1, int.MaxValue)]
    public int Quantity { get; set; }

    [Range (0.01, double.MaxValue)]
    public decimal Price { get; set; }
}

// Validation Execution - productRequest is an endpoint argument for accepting user input
var validationResults = new List<ValidationResult> ();
var context = new ValidationContext (productRequest);
bool isValid = Validator.TryValidateObject (productRequest, context, validationResults, true);

This method provides a simple and effective way to enforce constraints without relying on additional libraries.

Third-Party Validation (FluentValidation)

FluentValidation is a widely used third-party NuGet package that provides a flexible and expressive way to define validation rules. Unlike attribute-based validation, FluentValidation offers a programmatic approach to defining conditions.

Example...

public class CreateProductValidator : AbstractValidator<CreateProductRequest>
{
    public CreateProductValidator()
    {
        RuleFor (x => x.Name)
            .NotEmpty ().WithMessage ("Product name must not be empty.")
            .MaximumLength (100).WithMessage ("Product name must not be greater than 100 characters.");

        RuleFor (x => x.Description)
            .MaximumLength (500);

        RuleFor (x => x.Quantity)
            .GreaterThan (0);

        RuleFor (x => x.Price)
            .GreaterThan (0);
    }
}

// In Asp Net Core application, one would rather inject the IValidator<CreateProductRequest> either in the middleware, or endpoint/controller.
// Instead of creating the instance, the value will come as an argument to the endpoint/controller method.
CreateProductRequest request = new()
{
    Name = "Gaming Laptop",
    Description = "A high-performance laptop with advanced graphics for gaming.",
    Quantity = 69,
    Price = 999.99
};

CreateProductValidator validator = new();

var validationResult = await validator.ValidateAsync (request);

if (!validationResult.IsValid)
{
    foreach (var validationError in validationResult.Errors)
    {
        WriteLine ($"Property '{validationError.PropertyName}' failed validation. " +
            $"Error: { validationError.ErrorMessage}");
    }
}
else
{
    WriteLine ("Validation Passed!");
}

Best Practices for FluentValidation:

Define validation rules in separate classes to ensure clean separation of concerns.
Register validators in the Dependency Injection (DI) container to enable automatic validation at runtime.
Avoid excessive validation complexity within validator classes. Keep rules simple and maintainable.

Middleware Validation

For broader request validation, implementing validation logic within middleware ensures that data is processed before reaching controllers, improving efficiency and reducing redundancy.

Example...

Middleware can intercept incoming requests and check for validation errors before executing business logic.

app.Use (async (context, next) =>
{
    var errors = ValidateRequest (context);
    if (errors.Any ())
    {
        context.Response.StatusCode = StatusCodes.Status400BadRequest;
        await context.Response.WriteAsync (JsonConvert.SerializeObject(errors));
        return;
    }

    await next (context);
});

private List<string> ValidateRequest(HttpContext context)
{
    var errors = new List<string>();

    // Try to parse the request body into CreateProductRequest object
    context.Request.EnableBuffering();

    using (var reader = new StreamReader(context.Request.Body, Encoding.UTF8, leaveOpen: true))

    var body = reader.ReadToEnd();
    context.Request.Body.Position = 0;

    if (!string.IsNullOrEmpty(body))
    {
        try
        {
            var request = JsonConvert.DeserializeObject<CreateProductRequest>(body);
            if (request is not null)
            {
                var validationContext = new ValidationContext(request);
                var validationResults = new List<ValidationResult>();

                if (!Validator.TryValidateObject(request, validationContext, validationResults, true))
                {
                    errors.AddRange(validationResults.Select(x => x.ErrorMessage));
                }
            }
            else
                errors.Add("Invalid request payload.");
        }
        catch (Exception)
        {
            errors.Add("Error parsing request body.");
        }
    }
    else
        errors.Add("Request body cannot be empty.");

    return errors;
}

Middleware-based validation is particularly useful for enforcing global request policies, such as checking authentication tokens, request size limits, or content-type validation.

Controller/Endpoint Validation

Direct validation within controller actions ensures that each incoming request adheres to expected constraints before execution.

Example...

[HttpPost]
public IActionResult CreateProduct([FromBody] CreateProductRequest request)
{
    if (!ModelState.IsValid)
        return BadRequest(ModelState);

    // Proceed with request processing (e.g., saving to database)

    return Ok(new { Message = "Product created successfully!" });
}

While this approach is effective, placing validation at the endpoint level can lead to repetitive logic across multiple controllers. Consider using filters or middleware for a more centralized validation mechanism.

Choosing the Right Validation Strategy

Selecting the appropriate validation approach depends on the complexity of your application and specific requirements.

Validation Approach	Use Case	Complexity
Built-in Validation	Simple DTO validation with attributes	Low
Fluent Validation	Customizable and reusable validation rules	Moderate
Middleware	Global validation before request execution	High
Endpoint	Specific request validation at the controller	Moderate

Combining multiple validation methods ensures robustness while maintaining modularity. Use built-in validation for basic constraints, FluentValidation for complex validation logic, and middleware for handling global rules efficiently.

Repository Pattern (Optional)

The repository pattern is a popular way to abstract data access logic and improve testability. However, for simple CRUD applications, it can introduce unnecessary complexity. Consider using the repository pattern when:

You need to support multiple data sources
You want to add custom data access logic
You need to improve testability for complex business logic

For small or straightforward projects, direct use of DbContext is often sufficient and easier for beginners.

Conclusion

This architecture provides a well-structured, scalable, and maintainable approach to API development. By following best practices in entity modeling, DTO structuring, and validation strategies, developers can build robust APIs that ensure data integrity and high performance.

Key Takeaways

Organize your project for clarity and maintainability.
Use DTOs to separate API contracts from internal models.
Choose validation strategies that fit your application's complexity.
Apply the repository pattern only when it adds value.

About the Author

Hi, I’m Jiten Shahani, a passionate developer with a strong background in API development and C# programming. Although I’m new to .NET, my journey into learning ASP .NET Core began in December 2024, driven by a desire to build scalable and maintainable applications.

Feel free to connect with me to exchange ideas and learn together!

Repository Pattern – ASP.NET Core Web API

Jiten Shahani — Mon, 26 May 2025 13:55:07 +0000

This guide will help you, as a newcomer to ASP.NET Core, understand how to structure a web API project that interacts with a database. The project demonstrates three different data access approaches: direct use of the DbContext, the repository pattern, and the generic repository pattern. You’ll learn not only how to follow the code, but also why each approach is useful as your projects grow.

Technology Stack & NuGet Packages

This project leverages modern .NET technologies and best practices:

.NET 9.0:                 The latest version of the .NET platform, providing enhanced performance and modern language features.
C# 13.0:                  Utilizing the latest C# language features including record types, nullable reference types, and enhanced pattern matching.
ASP.NET Core:             Microsoft's cross-platform, high-performance framework for building modern, cloud-based, internet-connected applications.
Entity Framework Core:    A lightweight, extensible, and cross-platform Object-Relational Mapper (ORM) for .NET.
SQLite:                   A self-contained, serverless, zero-configuration database engine used as the data store.
OpenAPI:                  For automatic API documentation and testing interface.
Minimal APIs:             A simplified approach to building HTTP APIs with ASP.NET Core, focusing on reducing ceremony and boilerplate code.

This project uses the following NuGet packages:

Package Name	Purpose	Version
`Microsoft.AspNetCore.OpenApi`	Adds OpenAPI/Swagger support for API docs	9.0.4
`Microsoft.EntityFrameworkCore`	Entity Framework Core ORM	9.0.4
`Microsoft.EntityFrameworkCore.Sqlite`	SQLite provider for EF Core	9.0.4
`Microsoft.EntityFrameworkCore.Tools`	Design-time tools for EF Core (migrations)	9.0.4

What are NuGet packages?
NuGet is the package manager for .NET. Packages are reusable libraries you can add to your project to avoid writing everything from scratch.

Project Structure Overview

A well-structured project is easier to understand and maintain. Here’s how this demo is organized:

RepositoryPatternDemo/
├── Entities/                   # Contains models representing database entities, with properties directly mapped to table columns.
├── Data/                       # Contains the `AppDbContext`, which is your gateway to the database.
├── Dtos/                       # Defines Data Transfer Objects (DTO's) for request and response handling, ensuring data encapsulation and structured communication.
├── Repositories/               # Implements data access logic, effectively separating it from core business operations.
├── Endpoints/                  # Defines API endpoints responsible for handling HTTP requests and responses.
└── Program.cs                  # Application startup and configuration

Entity Models

Entity models are C# classes that map directly to database tables.

Product

public sealed class Product
{
    public Guid Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public string Description { get; set; } = string.Empty;
    public int Quantity { get; set; }
    public decimal Price { get; set; }
}

Customer

public sealed class Customer
{
    public Guid Id { get; set; }
    public string CompanyName { get; set; } = string.Empty;
    public string ContactName { get; set; } = string.Empty;
    public string ContactTitle { get; set; } = string.Empty;
    public string Address { get; set; } = string.Empty;
    public string City { get; set; } = string.Empty;
    public string PostalCode { get; set; } = string.Empty;
    public string Country { get; set; } = string.Empty;
    public string Phone { get; set; } = string.Empty;
    public string? Fax { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
}

Data Transfer Objects (DTOs)

DTOs define the data structure for creating and updating Products and Customers via the API. They help keep your API contracts clean and separate from your database models.

CreateProductRequest

public sealed record CreateProductRequest(
    string Name,
    string Description,
    int Quantity,
    decimal Price
);

Purpose

Used when creating a new product.

Example JSON

{
  "name": "Gaming Laptop",
  "description": "A high-performance laptop with advanced graphics for gaming.",
  "quantity": 10,
  "price": 999.99
}

UpdateProductRequest

public sealed record UpdateProductRequest(
    Guid Id,
    string Name,
    string Description,
    int Quantity,
    decimal Price
);

Purpose

Used when updating an existing product.

Example JSON

{
  "id": "01969b65-305c-75ae-bade-3c9d18855d5d",
  "name": "Gaming Mice",
  "description": "A high-performance low-latency lightweight mice for gaming.",
  "quantity": 22,
  "price": 68.99
}

CreateCustomerRequest

public sealed record CreateCustomerRequest(
    string CompanyName,
    string ContactName,
    string ContactTitle,
    string Address,
    string City,
    string PostalCode,
    string Country,
    string Phone,
    string? Fax,
    string Email
);

Purpose

Used when creating a new customer.

Example JSON:

{
  "companyName": "Dummy Company",
  "contactName": "John Doe",
  "contactTitle": "Owner",
  "address": "919 Williams Court, Brooklyn",
  "city": "New York",
  "postalCode": "11225",
  "country": "United States of America",
  "phone": "+ 1-212-391 7668",
  "fax": "",
  "email": "sales@dummyco.com"
}

UpdateCustomerRequest

public sealed record UpdateCustomerRequest(
    Guid Id,
    string CompanyName,
    string ContactName,
    string ContactTitle,
    string Address,
    string City,
    string PostalCode,
    string Country,
    string Phone,
    string? Fax,
    string Email
);

Purpose

Used when updating an existing customer.

Example JSON

{
  "id": "01969b6f-7399-7d3a-811e-b764befb8bd6",
  "companyName": "Dummy Company",
  "contactName": "John Doe",
  "contactTitle": "Managing Director",
  "address": "919 Williams Court, Brooklyn",
  "city": "New York",
  "postalCode": "11225",
  "country": "United States of America",
  "phone": "+ 1-212-391 7668",
  "fax": "+ 1-212-391 7669",
  "email": "sales@dummyco.com"
}

Summary Table

DTO Name	Used For	Required Fields
CreateProductRequest	Creating a product	Name, Description, Quantity, Price
UpdateProductRequest	Updating a product	Id, Name, Description, Quantity, Price
CreateCustomerRequest	Creating a customer	CompanyName, ContactName, ContactTitle, Address, City, PostalCode, Country, Phone, Fax (optional), Email
UpdateCustomerRequest	Updating a customer	Id, CompanyName, ContactName, ContactTitle, Address, City, PostalCode, Country, Phone, Fax (optional), Email

Data Access Approaches

Direct DbContext Usage

What is it?

Endpoints interact directly with the database context (AppDbContext).

Example

productGroup.MapGet("/", async (AppDbContext dbContext, CancellationToken cancellationToken) =>
{
    var products = await dbContext.Products.ToListAsync(cancellationToken);
    return TypedResults.Ok(products);
});

When to use

Learning or prototyping
Very simple applications

Repository Pattern

What is it?

You create a repository class for each entity (e.g., ProductRepository). The repository handles all database operations for that entity, keeping your endpoints clean and focused.

Example Interface

public interface IProductRepository
{
    Task<List<Product>> GetAllAsync(CancellationToken cancellationToken);
    Task<Product?> GetByIdAsync(Guid id, CancellationToken cancellationToken);
    Task AddAsync(Product product, CancellationToken cancellationToken);
    Task UpdateAsync(Product product, CancellationToken cancellationToken);
    Task DeleteAsync(Product product, CancellationToken cancellationToken);
}

When to use

Medium to large applications
When you want to separate concerns and improve testability

Generic Repository Pattern

What is it?

A single repository class (Repository<TEntity>) can handle all entities, using generics.

Example Interface

public interface IRepository<TEntity> where TEntity : class
{
    Task<List<TEntity>> GetAllAsync(CancellationToken cancellationToken);
    Task<TEntity?> GetByIdAsync(Guid id, CancellationToken cancellationToken);
    Task AddAsync(TEntity entity, CancellationToken cancellationToken);
    Task UpdateAsync(TEntity entity, CancellationToken cancellationToken);
    Task DeleteAsync(TEntity entity, CancellationToken cancellationToken);
}

When to use

Applications with many similar entities
When you want to avoid code duplication

Benefits Comparison

Approach	Simplicity	Scalability	Testability	Code Duplication
Direct DbContext	High	Low	Low	High
Repository Pattern	Medium	High	High	Medium
Generic Repository Pattern	Medium	High	High	Low

API Endpoints

Your API exposes endpoints for both products and customers, grouped by the data access pattern used.

1. Product Endpoints

A. Direct DbContext Usage (`/products`)

HTTP Method	Route	Description
GET	`/products`	Get a list of all products.
GET	`/products/{id}`	Get a single product by its unique ID.
POST	`/products`	Create a new product.
PUT	`/products`	Update an existing product (all fields).
DELETE	`/products/{id}`	Delete a product by its unique ID.

B. Repository Pattern (`/productsWithRPattern`)

HTTP Method	Route	Description
GET	`/productsWithRPattern`	Get a list of all products using the repository.
GET	`/productsWithRPattern/{id}`	Get a product by ID using the repository.
POST	`/productsWithRPattern`	Create a new product using the repository.
PUT	`/productsWithRPattern`	Update a product using the repository.
DELETE	`/productsWithRPattern/{id}`	Delete a product by ID using the repository.

C. Generic Repository Pattern (`/productsWithGRPattern`)

HTTP Method	Route	Description
GET	`/productsWithGRPattern`	Get all products using the generic repository.
GET	`/productsWithGRPattern/{id}`	Get a product by ID using the generic repository.
POST	`/productsWithGRPattern`	Create a new product using the generic repository.
PUT	`/productsWithGRPattern`	Update a product using the generic repository.
DELETE	`/productsWithGRPattern/{id}`	Delete a product by ID using the generic repository.

2. Customer Endpoints

A. Repository Pattern (`/customersWithRPattern`)

HTTP Method	Route	Description
GET	`/customersWithRPattern`	Get a list of all customers using the repository.
GET	`/customersWithRPattern/{id}`	Get a customer by ID using the repository.
POST	`/customersWithRPattern`	Create a new customer using the repository.
PUT	`/customersWithRPattern`	Update a customer using the repository.
DELETE	`/customersWithRPattern/{id}`	Delete a customer by ID using the repository.

B. Generic Repository Pattern (`/customersWithGRPattern`)

HTTP Method	Route	Description
GET	`/customersWithGRPattern`	Get all customers using the generic repository.
GET	`/customersWithGRPattern/{id}`	Get a customer by ID using the generic repository.
POST	`/customersWithGRPattern`	Create a new customer using the generic repository.
PUT	`/customersWithGRPattern`	Update a customer using the generic repository.
DELETE	`/customersWithGRPattern/{id}`	Delete a customer by ID using the generic repository.

Each group supports:

GET: Retrieve all or by ID
POST: Add new
PUT: Update existing
DELETE: Remove by ID

Setup and Configuration

Connection String

The connection string tells your app where to find the database. For SQLite, it’s as simple as:

{
  "ConnectionStrings": {
    "Database": "Data Source=Data\\AppDB.db"
  }
}

Service Registration

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlite(builder.Configuration.GetConnectionString("Database")));

builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddScoped<ICustomerRepository, CustomerRepository>();
builder.Services.AddScoped(typeof(IRepository<>), typeof(Repository<>));

JSON Serialization

To ensure your API responses are easy to work with:

builder.Services.Configure<JsonOptions>(options =>
{
    options.SerializerOptions.PropertyNamingPolicy = null;
    options.SerializerOptions.PropertyNameCaseInsensitive = true;
    options.SerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles;
    options.SerializerOptions.WriteIndented = true;
});

Testing the API

Swagger UI: Run your project and navigate to /swagger in your browser for interactive API documentation and testing.
Postman/cURL: You can also test endpoints using tools like Postman or the curl command.

Example cURL

curl -X GET https://localhost:5001/productsWithGRPattern

Conclusion and Recommendations

Start simple with direct DbContext usage for learning or tiny projects.
Adopt the Repository Pattern as your application grows, to keep code organized and testable.
Use the Generic Repository Pattern to avoid repetition, especially with many similar entities.
Best Practices:
- Use dependency injection for all services.
- Keep your entity models and DTOs separate.
- Always validate input and handle errors gracefully.
- Use AsNoTracking() for read-only queries to improve performance.

Key Takeaways

Start simple with direct DbContext usage for learning or tiny projects.
Adopt the repository pattern as your application grows to keep code organized and testable.
Use the generic repository pattern to avoid repetition, especially with many similar entities.
The repository pattern improves testability and separation of concerns by abstracting data access logic.
Minimal APIs in ASP.NET Core allow you to build HTTP APIs with less ceremony and boilerplate code.
Use dependency injection and keep your API contracts (DTOs) separate from your entity models for maintainability.

About the Author

Feel free to connect with me to exchange ideas and learn together!

Understanding Service Registration & Keyed Services in Dependency Injection

Jiten Shahani — Mon, 26 May 2025 13:18:29 +0000

Introduction

Dependency Injection (DI) is a powerful design pattern that helps decouple dependencies, making applications more testable, flexible, and maintainable. In .NET, the ServiceCollection provides a structured way to register dependencies, but choosing the right approach is crucial.

In this article, you'll learn:

Standard service registration in DI
Handling multiple implementations with IEnumerable<IMessageService>
Using keyed service registration to resolve specific implementations (requires .NET 8+ or a compatible DI container)

By understanding these techniques, you'll be able to register, resolve, and manage dependencies effectively in your applications.

Let’s dive in! 🚀

Example Dependencies

Before diving into service registration, let’s define some dependencies:


public interface IMessageService
{
    void SendMessage(string message);
}

public class EMailService : IMessageService
{
    public void SendMessage(string message) =>
        Console.WriteLine($"EMail message sent: {message}");
}

public class SMSService : IMessageService
{
    public void SendMessage(string message) =>
        Console.WriteLine($"SMS message sent: {message}");
}

public class DefaultProcessor
{
    private readonly IMessageService _messageService;

    public DefaultProcessor (IMessageService messageService)
    {
        _messageService = messageService;
    }

    public void ProcessMessage (string message)
    {
        _messageService.SendMessage (message);
    }
}

public class MessageProcessor
{
    private readonly IEnumerable<IMessageService> _messageServices;
    private readonly IServiceProvider _serviceProvider;

    public MessageProcessor (IEnumerable<IMessageService> messageServices, IServiceProvider serviceProvider)
    {
        _messageServices = messageServices;
        _serviceProvider = serviceProvider;
    }

    public void ProcessMessage (string message)
    {
        // Iterate through all the services registered as IMessageService.
        foreach (var service in _messageServices)
            service.SendMessage (message);
    }

    public void ProcessMessage (string message, MyServiceType serviceType)
    {
        var service = _serviceProvider.GetRequiredKeyedService<IMessageService> (serviceType);
        service.SendMessage (message);
    }
}

public enum MyServiceType
{
    EMail,
    SMS
}

These services implement IMessageService, allowing us to register them in DI. Now, let’s explore different registration methods.

Standard Service Registration in Dependency Injection

The most common way to register services in DI is using AddSingleton, AddScoped, or AddTransient. Here, we register multiple services against the same interface.

Example


ServiceProvider serviceProvider = new ServiceCollection()
    .AddSingleton<IMessageService, EMailService>()  // First registration
    .AddSingleton<IMessageService, SMSService>()   // Last registration overrides previous ones
    .AddSingleton<DefaultProcessor>()
    .AddSingleton<MessageProcessor>()
    .BuildServiceProvider();

// Resolving default service (only last registered IMessageService is used)
DefaultProcessor defaultProcessor = serviceProvider.GetRequiredService<DefaultProcessor>();
defaultProcessor.ProcessMessage("Hello, Default behavior. Dependency Injection!");

Issue

When multiple services are registered under the same interface (IMessageService), only the last registered service (SMSService) will be used. This may not always be the intended behavior.

Solution

To resolve multiple implementations, we can inject IEnumerable<IMessageService>.

Handling Multiple Implementations with `IEnumerable<IMessageService>`

If we register multiple implementations of IMessageService, we can inject IEnumerable<IMessageService> to iterate through all implementations.

Example


MessageProcessor messageProcessor = serviceProvider.GetRequiredService<MessageProcessor>();
messageProcessor.ProcessMessage("Hello, Dependency Injection!");

Inside MessageProcessor, we loop through all available implementations


public class MessageProcessor
{
    private readonly IEnumerable<IMessageService> _messageServices;

    public MessageProcessor(IEnumerable<IMessageService> messageServices)
    {
        _messageServices = messageServices;
    }

    public void ProcessMessage(string message)
    {
        foreach (var service in _messageServices)
            service.SendMessage(message);
    }
}

Result

Both EMailService and SMSService will process the message.

Use Case

This technique is useful when all implementations need to be executed, such as logging to multiple outputs or notifying multiple users.

Using Keyed Service Registration

Keyed service registration allows developers to resolve specific implementations based on a unique key.

Example


ServiceProvider serviceProvider = new ServiceCollection()
    .AddKeyedSingleton<IMessageService, EMailService>(MyServiceType.EMail)
    .AddKeyedSingleton<IMessageService, SMSService>(MyServiceType.SMS)
    .AddSingleton<MessageProcessor>()
    .BuildServiceProvider();

MessageProcessor messageProcessor = serviceProvider.GetRequiredService<MessageProcessor>();

// Resolving specific services using keys
messageProcessor.ProcessMessage("Hello, Dependency Injection!", MyServiceType.EMail);
messageProcessor.ProcessMessage("Hello, Dependency Injection!", MyServiceType.SMS);

Advantages of Keyed Services

Explicit Control – Developers choose which implementation to use at runtime.
Improved Testability – Easier to test specific scenarios.
Better Performance – Avoid unnecessary object creation.

Implementation in MessageProcessor


public class MessageProcessor
{
    private readonly IServiceProvider _serviceProvider;

    public MessageProcessor(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public void ProcessMessage(string message, MyServiceType serviceType)
    {
        var service = _serviceProvider.GetRequiredKeyedService<IMessageService>(serviceType);
        service.SendMessage(message);
    }
}

Result

Depending on the passed key (MyServiceType.EMail or MyServiceType.SMS), the correct service is resolved.

Use Case

Useful in multi-tenant applications, message routing, and strategy-based pattern implementations.

Common Pitfalls

While using Dependency Injection, developers often make mistakes that affect performance and maintainability. Here are some pitfalls to avoid:

Common Pitfalls

Registering Multiple Services Without `IEnumerable<IMessageService>`

Issue: If multiple services are registered under the same interface (IMessageService), only the last registered service is used, leading to unexpected behavior.
Example: Registering both EMailService and SMSService under IMessageService but only one gets resolved.
Solution: Inject IEnumerable<IMessageService> to process all registered services.

Overusing Singleton Dependencies

Issue: Using too many singletons may introduce shared state, causing unintended side effects in multi-threaded applications.
Example: A singleton logging service storing mutable state incorrectly.
Solution: Ensure singleton services are truly stateless, or use locks for thread safety.

Injecting Too Many Dependencies Into a Single Class

Issue: Having too many constructor parameters may indicate poor design, making maintenance harder.
Example: A service requiring 10 injected dependencies becomes unwieldy.
Solution: Consider grouping related dependencies into helper classes or using facade patterns.

Misconfigured Dependency Lifetimes

Issue: Using singleton dependencies for stateful objects can lead to unintended behaviors.
Example: A database connection should not be a singleton. It might retain stale data.
Solution: Use Scoped lifetime for request-bound objects and Transient for short-lived services.

Using Service Locator Instead of Direct Injection

Issue: Fetching dependencies manually via _serviceProvider.GetRequiredService<T>() inside services creates hidden dependencies, reducing testability.
Example: A class resolving dependencies dynamically instead of having them injected.
Solution: Prefer constructor injection for better readability and testability.
Exception: Using serviceProvider.GetRequiredService<T>() inside middleware or entry points is acceptable.

Not Disposing Dependencies Properly

Issue: Forgetting to dispose of IDisposable services results in resource leaks.
Example: Not disposing DbContext in an EF Core application leads to excessive memory consumption.
Solution: Use Scoped dependencies for disposable objects and implement IAsyncDisposable where necessary.

Best Practices

Choose the Right Lifetime Scope – Use Transient for lightweight services, Scoped for request-specific objects, and Singleton for shared dependencies.
Keep Dependencies Minimal – Avoid excessive injection; group related dependencies logically.
Use Constructor Injection Over Property Injection – Constructor injection ensures dependencies exist when the object is instantiated.
Use IoC Containers Efficiently – Register services properly, avoid redundant registrations, and ensure correct dependency resolution.
Test Dependencies with Mocking Frameworks – Use Moq or FakeItEasy to create mock dependencies instead of relying on real implementations.

Key Takeaways

Standard DI registration uses the last-registered service for a given interface.
Use IEnumerable<T> to resolve and use all registered implementations of an interface.
Keyed services (in .NET 8+ or compatible containers) allow resolving a specific implementation by key.
Always choose the right service lifetime (Transient, Scoped, Singleton) for your scenario.
Avoid common pitfalls: hidden dependencies, overusing singletons, and misconfigured lifetimes.
Prefer constructor injection for clarity and testability.

Final Thoughts

Understanding common pitfalls and best practices ensures a smooth and efficient DI setup. Avoid hidden dependencies, misconfigured lifetimes, and over-injected classes to keep your application scalable, maintainable, and testable. By following DI best practices, developers can write cleaner, more efficient, and modular applications while avoiding technical debt.

Understanding service registration techniques in Dependency Injection is crucial for maintainable, scalable, and flexible applications. This article explored:

Standard DI registration, showing how last-registered services override previous ones.
Using IEnumerable<T>, allowing multiple implementations to coexist.
Leveraging Keyed Services, enabling explicit control over service resolution.

Choosing the right DI strategy depends on your application needs. Whether you're building an Asp Net Core API, a background service, or a multi-tenant system, understanding how services are registered and resolved ensures better architecture and performance.

Start experimenting with IEnumerable and Keyed Services, and you’ll have a more flexible, maintainable DI setup in your projects.

About the Author

Through my exploration of dependency injection, I’ve realized how crucial it is for writing flexible, testable, and loosely coupled code. This article is a reflection of my learning process, aimed at helping fellow developers, especially beginners, understand the different ways to inject dependencies effectively in C#.

Feel free to connect with me to exchange ideas and learn together!

Mastering Service Registration in Dependency Injection

Jiten Shahani — Mon, 26 May 2025 13:13:28 +0000

📖 Introduction

Dependency Injection (DI) is a fundamental design pattern that plays a crucial role in modern software development. It helps decouple dependencies, enhances testability, and allows for flexible service management, making applications more scalable and maintainable.

In traditional programming, classes often instantiate their dependencies directly, leading to tight coupling and making it difficult to modify or test components. DI solves this problem by injecting dependencies externally, allowing components to work independently while promoting separation of concerns.

This article explores different ways to register services in DI containers, helping developers understand how dependencies are managed within an application. Whether you are building a simple console app, an ASP.NET Core API, or a large-scale enterprise application, understanding these techniques will help you make informed design decisions.

By the end of this article, you'll have a clear understanding of the available DI registration approaches, their pros and cons, and best practices to ensure an efficient, well-structured application.

Let's dive in! 🚀

Example Dependencies


public interface IMessageService
{
    void SendMessage (string message);
}

public class EMailService : IMessageService
{
    public void SendMessage (string message) =>
        Console.WriteLine ($"EMail message sent: {message}");
}

public class SMSService : IMessageService
{
    public void SendMessage (string message) =>
        Console.WriteLine ($"SMS message send: {message}");
}

public class MessageProcessor
{
    private readonly IMessageService _messageService;

    public MessageProcessor (IMessageService messageService) =>
        _messageService = messageService;

    public void ProcessMessage (string message) =>
        _messageService.SendMessage (message);
}

Approaches to Service Registration

In this article, we will cover four approaches to service registration:

Manual Instance Creation
Using Microsoft.Extensions.DependencyInjection (ServiceProvider & ServiceCollection classes)
Using IHost & IHostBuilder for DI Management
Third-Party DI Containers like Autofac

1️⃣ Manual Instance Creation

Manual DI involves explicitly creating instances of dependencies inside a class. While simple, it leads to tight coupling and can be difficult to scale as applications grow.

Example


// Manual dependency instantiation
IMessageService messageService = new EMailService();

// Calling the method directly
messageService.SendMessage("Hello, Manual Dependency Injection!");

// Constructor injecting service instance into MessageProcessor
MessageProcessor messageProcessorManual = new (messageService);
messageProcessorManual.ProcessMessage("Hello, Manual Dependency Injection! Inject instance as service.");

🌟 Advantages

Simple and easy to understand.
No external dependencies or frameworks required.
Gives direct control over dependency creation.

❌ Disadvantages

Leads to tight coupling, making future changes difficult.
Harder to manage dependencies in large applications.
Testing becomes challenging, as dependencies can't be easily mocked.

📌 Use Case

Best for small applications or proof-of-concept implementations.
Suitable for one-off scripts where DI is not needed.
Useful in early development stages before a full DI system is required.

2️⃣ Using Microsoft.Extensions.DependencyInjection NuGet Package

.NET provides built-in DI support via ServiceCollection & ServiceProvider classes. This method is flexible and integrates well with ASP.NET Core and allows automatic dependency resolution.

Example


// Required NuGet package: Microsoft.Extensions.DependencyInjection

// Registering dependencies
ServiceProvider serviceProvider = new ServiceCollection()
    .AddSingleton<IMessageService, EMailService>()
    .AddSingleton<MessageProcessor>()
    .BuildServiceProvider();

// Resolving services
MessageProcessor messageProcessor = serviceProvider.GetRequiredService<MessageProcessor>();
messageProcessor.ProcessMessage("Hello, Dependency Injection!");

🌟 Advantages

Built-in support for .NET & ASP.NET Core applications.
Automatic dependency resolution without manual instantiation.
Scalable approach for managing dependencies in large projects.

❌ Disadvantages

Requires understanding DI configuration & service lifetimes.
Limited features compared to advanced third-party containers.
Can introduce slight performance overhead if misconfigured.

📌 Use Case

Best for ASP.NET Core applications where DI is widely used.
Ideal for scalable architectures with complex dependency chains.
Suitable for teams using .NET's standard DI system.

3️⃣ Using IHost & IHostBuilder for DI Management

IHost provides a structured way to manage dependencies, logging, and application lifetimes. It is widely used in ASP.NET Core and worker services.

Example


// Required NuGet packages: Microsoft.Extensions.Hosting, Microsoft.Extensions.DependencyInjection

IHost host = Host.CreateDefaultBuilder()
    .ConfigureServices((context, service) =>
    {
        service.AddSingleton<IMessageService, EMailService>();
        service.AddSingleton<MessageProcessor>();
    })
    .Build();

// Resolving services
MessageProcessor messageProcessorHost = host.Services.GetRequiredService<MessageProcessor>();
messageProcessorHost.ProcessMessage("Hello, Dependency Injection with IHost!");

🌟 Advantages

Provides structure for managing application lifecycles & configuration.
Consistent with how DI is handled in ASP.NET Core.
Supports hosted services and background tasks.

❌ Disadvantages

Adds complexity, especially for simple console applications.
Slight overhead due to extra structure & service management.

📌 Use Case

Best for ASP.NET Core applications, worker services, and background tasks.
Ideal for applications requiring structured lifetime management.
Suitable when integrating logging, configuration, and hosted services.

4️⃣ Third-Party DI Containers (Autofac, Ninject, SimpleInjector)

Third-party DI frameworks like Autofac provide advanced dependency management, including module registration, property injection, and lifetime scopes.

Example


// Required NuGet package: Autofac
ContainerBuilder builder = new();

// Registering services
builder.RegisterType<EMailService>().As<IMessageService>();
builder.RegisterType<MessageProcessor>();

IContainer container = builder.Build();
using ILifetimeScope scope = container.BeginLifetimeScope();

// Resolving services
MessageProcessor messageProcessorAutofac = scope.Resolve<MessageProcessor>();
messageProcessorAutofac.ProcessMessage("Hello, Autofac Dependency Injection!");

🌟 Advantages

Supports advanced features like module-based configurations.
Highly flexible & customizable dependency management.
Provides fine-grained control over dependency lifetimes.

❌ Disadvantages

Adds extra dependencies to the project.
Steeper learning curve compared to built-in DI frameworks.
May require additional effort to integrate with .NET Core.

⚡ Comparison Summary

Approach	Pros	Cons
Manual Dependency Injection	Simple & direct	Not scalable, hard to manage
Microsoft.Extensions.DependencyInjection	Integrated with .NET	Limited features, not for all scenarios
IHost & IHostBuilder	Provides structured DI	Adds complexity
Third-Party Containers (Autofac, etc.)	Advanced features & flexibility	Extra dependencies, steeper learning curve

🔎 Service Lifetimes in DI

DI manages object lifetimes using three key scopes:

1️⃣ Transient – A new instance is created every time it's requested. Best for lightweight, stateless services.
2️⃣ Scoped – A single instance is maintained per request scope. Ideal for services that need to maintain state within a request.
3️⃣ Singleton – A single instance is shared across the application. Suitable for shared resources or services that are expensive to create.

Example


services.AddTransient<IMessageService, EMailService>();  // Creates a new instance each time
services.AddScoped<IMessageService, EMailService>();     // One instance per request scope
services.AddSingleton<IMessageService, EMailService>();  // Single instance shared across app

⚠ Common Pitfalls in Dependency Injection

While Dependency Injection simplifies service management, improper use can lead to performance bottlenecks, unnecessary complexity, or poor architectural decisions. Below are common mistakes to avoid, followed by best practices to follow:

1️⃣ Overusing Singleton Dependencies

Issue: Using too many singletons can cause unintended memory leaks or thread-safety issues.
Example: A singleton logging service might store state unexpectedly.
Solution: Ensure singletons are truly stateless or use locks for thread safety.

2️⃣ Injecting Too Many Dependencies

Issue: Having too many constructor parameters can indicate poor design.
Example: A service needing 10 different injected dependencies might need refactoring.
Solution: Consider grouping related dependencies into helper classes or using composition.

3️⃣ Misconfiguring Dependency Lifetimes

Issue: Using singleton dependencies for stateful objects can lead to unexpected behavior.
Example: A database connection should not be a singleton.
Solution: Use Scoped lifetime for objects tied to request scope and Transient for short-lived objects.

4️⃣ Using the Service Locator Pattern

Issue: Instead of injecting dependencies, developers sometimes retrieve them via a global service locator, leading to hidden dependencies and tightly coupled code.
Example: Using ServiceLocator.Resolve<IMessageService>() hides the dependency, making code harder to test and maintain compared to direct constructor injection.
Solution: Avoid the service locator pattern. Prefer explicit dependency injection via constructors or method parameters for better testability and maintainability.

5️⃣ Not Disposing Dependencies Properly

Issue: Forgetting to dispose of IDisposable services causes resource leaks.
Example: Not disposing DbContext in an EF Core application.
Solution: Use Scoped dependencies for disposable services or implement IAsyncDisposable.

✅ Best Practices in Dependency Injection

Choose the Right Lifetime Scope – Use Transient for lightweight services, Scoped for request-specific services, and Singleton for shared dependencies.
Keep Dependencies Minimal – Reduce unnecessary injections by grouping related dependencies into cohesive service classes.
Use Constructor Injection Over Property Injection – Constructor injection ensures dependencies exist when the object is created.
Use IoC Containers Efficiently – Avoid re-registering services, keep single responsibility, and ensure proper dependency resolution.
Test Dependencies with Mocking Frameworks – Use Moq or FakeItEasy to create mock dependencies instead of relying on real implementations.

📌 Conclusion

Dependency Injection is a powerful technique that significantly improves code organization, modularity, and testability. By injecting dependencies externally, developers reduce coupling, making applications easier to modify and scale.

This article explored multiple DI registration approaches, including:

Manual Instance Creation, which works for small applications but lacks scalability.
Microsoft.Extensions.DependencyInjection, offering seamless integration with .NET applications.
IHost & IHostBuilder, adding structure for managing dependencies efficiently in ASP.NET Core & worker services.
Third-party DI containers like Autofac, providing advanced features for complex applications.

Choosing the right approach depends on application complexity, performance considerations, and scalability needs. By following best practices, avoiding common pitfalls, and applying proper dependency lifetimes, developers can build robust, maintainable software that adheres to industry standards.

As you continue exploring DI, experiment with different registration methods, test out IoC containers, and refine your implementation strategies to achieve cleaner, more efficient software architectures.

📝 Key Takeaways

DI decouples components and improves testability, maintainability, and scalability.
Manual DI is simple but not scalable; use it only for small or throwaway projects.
Microsoft.Extensions.DependencyInjection is the standard for .NET and ASP.NET Core, balancing simplicity and power.
IHost & IHostBuilder add structure and are ideal for ASP.NET Core and background services.
Third-party containers (like Autofac) offer advanced features for complex scenarios.
Choose the right service lifetime (Transient, Scoped, Singleton) for each dependency.
Avoid common pitfalls: overusing singletons, injecting too many dependencies, misconfiguring lifetimes, using service locators, and forgetting to dispose resources.
Follow best practices: keep dependencies minimal, prefer constructor injection, and use mocking frameworks for testing.

📖 Further Reading

About the Author

Feel free to connect with me to exchange ideas and learn together!

Mastering Dependency Injection: Effective Ways to Inject Dependencies in C#

Jiten Shahani — Mon, 26 May 2025 05:58:21 +0000

Introduction

Dependency Injection (DI) is a design pattern that helps achieve Inversion of Control (IoC) between classes and their dependencies. It allows objects to receive their dependencies from an external source rather than creating them internally. This leads to loosely coupled code, making it easier to maintain, test, and extend. Imagine a builder constructing a house. Instead of running to buy tools every time he needs to work, someone provides the tools for him—allowing him to focus on construction. Similarly, Dependency Injection provides necessary dependencies to a class, improving efficiency and flexibility.

Modern frameworks like ASP .NET Core heavily rely on DI to manage dependencies effectively. Without DI, tightly coupled code can make maintenance and testing difficult, leading to rigid architectures.

Let's dive in! 🚀

What Are Dependencies in Dependency Injection?

In software development, dependencies are objects or components that a class requires to function properly. Think of dependencies as necessary tools that a class relies on to perform its tasks.

For example:

A Builder needs tools such as Saw and Hammer to construct something.
Instead of the Builder creating its own tools, the tools are provided externally, allowing more flexibility.

Example Dependencies

// Dependency
public class Saw
{
    public void Use()
    {
        Console.WriteLine("Sawing Wood!");
    }
}

// Dependency
public class Hammer
{
    public void Use()
    {
        Console.WriteLine("Hammering Nails!");
    }
}

Ways to Inject Dependencies in CSharp

There are four common ways to inject dependencies in C#:

Manual Injection (Instance Creation)
Constructor Injection (Commonly Used)
Setter Injection
Interface Injection

Manual Injection

In manual injection, dependencies are explicitly created inside the class itself.

Example:


public class Builder
{
    public void Build()
    {
        // Builder creates its own dependencies
        Saw saw = new();
        Hammer hammer = new();

        saw.Use();
        hammer.Use();

        Console.WriteLine("House Built!");
    }
}

// Usage
Builder builder = new();
builder.Build();

Advantages:

Simple and easy to implement without additional frameworks.
Full control over object instantiation and lifecycle.
No dependency resolution overhead from an IoC container.

Disadvantages:

Creates tightly coupled code, making future modifications harder.
Difficult to mock dependencies for unit testing.
Leads to poor maintainability and scalability in larger applications.

Use Case:

Best for small applications and one-off scripts where DI is unnecessary.
Useful in early development stages or proof-of-concept implementations.
Suitable for standalone utilities with minimal dependency management.

Constructor Injection

Dependencies are provided through the class constructor, ensuring they exist at the time of object instantiation.

Example:


public class BuilderConstructorInjection
{
    private readonly Saw _saw;
    private readonly Hammer _hammer;

    public BuilderConstructorInjection(Saw saw, Hammer hammer)
    {
        _saw = saw;
        _hammer = hammer;
    }

    public void Build()
    {
        _saw.Use();
        _hammer.Use();
        Console.WriteLine("House Built!");
    }
}

// Usage
BuilderConstructorInjection builderCI = new (new Saw(), new Hammer());
builderCI.Build();

Advantages:

Ensures required dependencies are available when the class is instantiated.
Makes code loosely coupled and easier to test.
Works seamlessly with IoC containers for automatic dependency resolution.

Disadvantages:

Requires dependencies at object creation, which can limit flexibility.
Can lead to long constructors when many dependencies are required.
Makes certain patterns (e.g., optional dependencies) harder to implement.

Use Case:

Ideal for scenarios where dependencies are mandatory and should not be modified after object creation.
Works well in ASP .NET Core and large-scale applications using DI frameworks.
Best suited for services, controllers, and core components that rely on stable dependencies.

Setter Injection

Dependencies are injected through public setter methods after the object is created.

Example:


public class BuilderSetterInjection
{
    public Saw? Saw { private get; set; }
    public Hammer? Hammer { private get; set; }

    public void Build()
    {
        Saw!.Use();
        Hammer!.Use();
        Console.WriteLine("House Built!");
    }
}

// Usage
BuilderSetterInjection builderSI = new();
builderSI.Saw = new Saw();
builderSI.Hammer = new Hammer();
builderSI.Build();

Advantages:

Allows dependencies to be modified after object creation, increasing flexibility.
Useful for optional or configurable dependencies that change at runtime.
Provides better control over lifecycle management compared to constructor injection.

Disadvantages:

Dependencies might be unset initially, leading to incomplete object states.
Requires additional validation to ensure dependencies are set before usage.
Can make debugging harder if a required dependency isn’t injected properly.

Use Case:

Ideal for UI components or dynamic configurations where dependencies may change.
Works well in scenarios where dependency availability depends on runtime conditions.
Suitable for factories, dynamically loaded services, and non-critical dependencies.

Interface Injection

Dependencies are provided through an interface that exposes a method for dependency injection.

Example:


public interface IBuilder
{
    void SetDependencies(Saw saw, Hammer hammer);
}

public class BuilderInterfaceInjection : IBuilder
{
    private Saw? _saw;
    private Hammer? _hammer;

    public void SetDependencies(Saw saw, Hammer hammer)
    {
        _saw = saw;
        _hammer = hammer;
    }

    public void Build()
    {
        _saw!.Use();
        _hammer!.Use();
        Console.WriteLine("House Built!");
    }
}

// Usage
BuilderInterfaceInjection builderII = new();
builderII.SetDependencies(new Saw(), new Hammer());
builderII.Build();

Advantages:

Maximizes flexibility by enforcing dependency provision via an interface.
Makes code more testable and interchangeable by allowing different implementations.
Often used in plugin-based architectures or systems requiring dependency swapping.

Disadvantages:

Requires objects to implement a specific interface, which may add complexity.
Can make the design more rigid if multiple interfaces must be implemented.
Overuse can lead to unnecessary abstraction and complexity in simple projects.

Use Case:

Best for modular applications where dependencies vary dynamically.
Frequently used in extensible frameworks, plugin-based systems, and middleware.
Ideal for scenarios requiring dependency injection without tight coupling to concrete classes.

Dependency Injection in ASP .NET Core

ASP .NET Core comes with built-in IoC containers, making DI implementation effortless.

Example:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<Saw>();
builder.Services.AddScoped<Hammer>();

This ensures dependencies are automatically provided without manual instantiation.

Why Use Dependency Injection?

Using DI improves software development in the following ways:

Reduces Coupling: Classes are independent of specific implementations.
Enhances Testability: Dependencies can be mocked for unit testing.
Improves Code Maintainability: Changing dependencies does not require modifying the dependent class.
Boosts Flexibility: Dependency changes can be handled without affecting core logic.

Common Pitfalls to Avoid

When implementing DI, watch out for these mistakes:

Overusing Singleton Dependencies – Can cause unintended side effects in multi-threaded applications.
Misconfigure IoC Containers – Incorrect service lifetimes (e.g., using Scoped dependencies in Singleton services).
Injecting Too Many Dependencies – A class with numerous dependencies may indicate poor design.
Using Service Locator Patterns – This can lead to hidden dependencies and make code harder to understand.

Best Practices for Dependency Injection

When implementing DI, follow these best practices:

Prefer Constructor Injection for mandatory dependencies.
Use IoC Containers to manage dependencies efficiently (e.g., ASP .NET Core's built-in DI, Autofac, Unity).
Avoid Service Locator Patterns, which introduce hidden dependencies.
Ensure Single Responsibility Principle (SRP) when handling dependency management.
Keep Dependencies Small & Specific, avoiding unnecessary dependency injections.

Performance Considerations

While DI improves maintainability, keep these performance factors in mind:

Object Creation Cost – Too many transient dependencies may affect performance.
Garbage Collection Load – Unnecessary object instantiation can increase memory usage.
Dependency Resolution Overhead – IoC containers add a small processing cost when resolving objects.
Service Lifetime Management – Ensure proper lifetimes (Transient, Scoped, Singleton) to avoid memory leaks.

This ensures that dependencies are managed and provided automatically without manual instantiation.

Common Misconceptions About Dependency Injection

Many beginners misinterpret Dependency Injection, leading to confusion about its purpose and implementation. Here are some common misconceptions:

DI is only for ASP .NET Core

DI is a general design pattern that works in any C# application, including console apps, desktop applications, and game development.
While ASP .NET Core has built-in support, DI can be implemented without a framework using manual or third-party IoC containers.

DI is just about using interfaces

Many think DI is just about programming to an interface (e.g., IService), but DI is about managing dependencies externally.
DI can work without interfaces (e.g., injecting concrete classes), although interfaces make swapping dependencies easier.

DI is too complex for small applications

DI doesn't require advanced frameworks. You can even apply DI principles manually in small projects.
Even a basic constructor injection approach can improve flexibility, making DI beneficial regardless of project size.

Using DI always improves performance

While DI improves maintainability, excessive use of IoC containers can introduce performance overhead due to object resolution costs.
Optimize DI by using scoped and singleton dependencies wisely and avoiding unnecessary object instantiations.

Dependency Injection Beyond ASP .NET Core

While DI is built into ASP .NET Core, it is a general design pattern that can be applied in many types of applications:

Console Applications: Manage dependencies in command-line tools.
Windows Forms & WPF Apps: Inject services for UI components.
Game Development: Manage game objects and services dynamically.
Microservices & Background Services: Handle dependency lifetimes in distributed or long-running processes.

The concept remains the same: instead of creating dependencies inside a class, you provide them externally to improve flexibility and maintainability.

Conclusion

Dependency Injection is more than just a design pattern. It is a fundamental principle that promotes flexibility, scalability, and maintainability in software development. By injecting dependencies externally, we decouple components, making applications easier to modify, test, and extend.

As applications grow in complexity, managing dependencies manually becomes increasingly impractical, leading to rigid and tightly coupled designs. DI addresses these challenges by allowing developers to swap implementations dynamically, integrate mock dependencies for testing, and manage lifetimes efficiently using IoC containers.

Whether you're building a simple console application, a large-scale ASP .NET Core project, or even game development services, Dependency Injection enhances code reusability, modularity, and testability. The beauty of DI lies in its versatility. It is not confined to a single framework but can be applied across various technologies.

Understanding different injection methods—constructor injection, setter injection, and interface injection—provides developers with the tools to create scalable architectures while avoiding common pitfalls. By following best practices and optimizing dependency lifetimes, developers can strike the perfect balance between maintainability and performance.

At its core, Dependency Injection encourages the principles of clean code and software craftsmanship, empowering developers to write robust, flexible, and future-proof applications. As you continue exploring DI, consider experimenting with different approaches, testing out IoC containers, and refining your implementation strategies to build high-quality, maintainable software.

Key Takeaways

Prefer constructor injection for required dependencies.
Use IoC containers to manage dependencies efficiently.
Avoid service locator patterns and overusing singletons.
DI is not just for ASP .NET Core—apply it in any C# project.
Always keep dependencies minimal and focused.

About the Author

Feel free to connect with me to exchange ideas and learn together!

DEV Community: Jiten Shahani

API Project Architecture

Project Structure

Entity Classes

Example

Utilizing a Base Entity Class

Base Entity Class Example

DbContext Example

Structuring DTO's

What is a DTO?

Best Practices:

Rules for Defining DTO's

DTO Examples

DTO Validation

Built-in Validation (Validator.TryValidateObject)

Example...

Third-Party Validation (FluentValidation)

Example...

Best Practices for FluentValidation:

Middleware Validation

Example...

Controller/Endpoint Validation

Example...

Choosing the Right Validation Strategy

Repository Pattern (Optional)

Conclusion

Key Takeaways

Further Reading

About the Author

Repository Pattern – ASP.NET Core Web API

Technology Stack & NuGet Packages

Project Structure Overview

Entity Models

Product

Customer

Data Transfer Objects (DTOs)

CreateProductRequest

Purpose

Example JSON

UpdateProductRequest

Purpose

Example JSON

CreateCustomerRequest

Purpose

Example JSON:

UpdateCustomerRequest

Purpose

Example JSON

Summary Table

Data Access Approaches

Direct DbContext Usage

What is it?

Example

When to use

Repository Pattern

What is it?

Example Interface

When to use

Generic Repository Pattern

What is it?

Example Interface

When to use

Benefits Comparison

API Endpoints

1. Product Endpoints

A. Direct DbContext Usage (/products)

B. Repository Pattern (/productsWithRPattern)

C. Generic Repository Pattern (/productsWithGRPattern)

2. Customer Endpoints

A. Repository Pattern (/customersWithRPattern)

B. Generic Repository Pattern (/customersWithGRPattern)

Setup and Configuration

Connection String

Service Registration

JSON Serialization

Testing the API

Example cURL

Conclusion and Recommendations

Key Takeaways

Further Reading

A. Direct DbContext Usage (`/products`)

B. Repository Pattern (`/productsWithRPattern`)

C. Generic Repository Pattern (`/productsWithGRPattern`)

A. Repository Pattern (`/customersWithRPattern`)

B. Generic Repository Pattern (`/customersWithGRPattern`)

Handling Multiple Implementations with `IEnumerable<IMessageService>`

Registering Multiple Services Without `IEnumerable<IMessageService>`