Organize Your ASP.NET Core DI Like a Pro! Move Service Registrations to a Separate Class for Clean, Scalable Code

Organizing your Dependency Injection (DI) setup in ASP.NET Core by moving service registrations to a separate class using extension methods is a simple yet powerful step toward writing cleaner, more maintainable, and scalable applications.

In modern ASP.NET Core (especially .NET 6 and later), the Program.cs file is the entry point of your web application. It:

    Builds your web host

    Sets up services (via DI)

    Configures middleware

    Starts the app

What Goes Wrong?

In small projects, you might only register a few services:

Program.cs looking like this:

builder.Services.AddScoped<IMyService, MyService>();

builder.Services.AddControllers();

But as the app grows:

Business logic gets more complex

The file becomes too long and messy.

It mixes service registration, routing, and app startup logic in one place.

It’s hard to read and harder to maintain.

If you want to update or replace a service, you have to dig through the clutter.

Now, Program.cs starts looking like this:

builder.Services.AddScoped<IMyService, MyService>();

builder.Services.AddScoped<IUserService, UserService>();

builder.Services.AddScoped<IEmailSender, SendGridEmailSender>();

builder.Services.AddScoped<IPaymentProcessor, StripeProcessor>();

builder.Services.AddScoped<IReportGenerator, PdfReportGenerator>();

builder.Services.AddDbContext<AppDbContext>(...);

builder.Services.AddAutoMapper(typeof(Startup));

builder.Services.AddControllers();

Solution

Move the service registrations to a separate file using an extension method. Then in Program.cs, you just call:

                builder.Services.DIScope();

Example 

1. Define service IGreetingService

namespace DIServiceExtension.Service

{

    public interface IGreetingSerice

    { 

        string Greet(string message);

    }

    public class GreetingService : IGreetingSerice

    {

        public string Greet(string message="Hello Developers...")

        {

            return message;

        }

    }

}

2. Define serivce IEmailSerice

using DIServiceExtension.Helper;


namespace DIServiceExtension.Service

{

    public interface IEmailService

    {

        string SendMail();

    }

    public class EmailService:IEmailService

    {

        private readonly HelperService _helperService;

        public EmailService(HelperService helperService)

        {

            _helperService = helperService;

        }

        public string SendMail()

        {

            return $"Mail sent successfully! on {_helperService.GetUTCDateTime()}";

        }

    }

}

3. Define HelperService

namespace DIServiceExtension.Helper

{

    public class HelperService

    {

        public DateTime GetUTCDateTime()

        {

            return DateTime.UtcNow;

        }

    }

}

4. Create an Extension Method 

using DIServiceExtension.Helper;

using DIServiceExtension.Service;

using Microsoft.Extensions.DependencyInjection;

namespace DIServiceExtension

{

    public static class ServiceExtension

    {

        /* public static void DIScope(this IServiceCollection services)

         {

             services.AddScoped<IEmailService, EmailService>();

             services.AddScoped<IGreetingSerice, GreetingService>();

             services.AddScoped<HelperService>();

         }*/

        public static IServiceCollection DIScope(this IServiceCollection services)

        {

            services.AddScoped<IEmailService, EmailService>();

            services.AddScoped<IGreetingSerice, GreetingService>();

            services.AddScoped<HelperService>();


            return services;

        }

    }

}

5. Use the Extension Method in Program.cs

                      builder.Services.DIScope();

The Benefits

1. Cleaner Code

    Program.cs is focused only on application startup

    DI logic is encapsulated in its own file

2. Better Separation of Concerns

    DI setup is not mixed with routing, middleware, or host configuration

    You can reuse or test the DI configuration independently

3. Easier Maintenance

    Adding a new service? Just update one centralized method.

    Need to switch to a different implementation? Update it in one place.

4. Scalability

    Large apps often register hundreds of services

    You can break your DI setup into multiple layers:

builder.Services

    .AddInfrastructureServices()

    .AddApplicationServices()

    .AddCustomServices();

Want to See It in Action?

If you'd like a visual walkthrough of everything covered in this post — with real code examples and a step-by-step explanation —

Check out my YouTube video here: Watch

Don’t forget to like, comment, and subscribe if you find it helpful!


Comments

Post a Comment

Popular posts from this blog

Understanding Middleware in .NET Core

Image
What is Middleware in ASP.NET Core? If you're starting to learn ASP.NET Core , you've probably heard the word "middleware" quite a few times. It might sound complicated at first, but don’t worry — in this post, we’ll break it down into simple terms . You’ll learn: What middleware is Why it's important How it works How to create your own Best practices (and things to avoid) What is Middleware in .NET Core? Middleware is a piece of code that sits between the incoming HTTP request and the outgoing HTTP response in an ASP.NET Core app. It can: Inspect or modify the request Handle authentication or logging Pass the request to the next step Or even stop the request entirely In simple words: Middleware is like a checkpoint that performs some logic on every request before it reaches your controller or API. Real-Life Analogy: The Airport Imagine you're at an airport going through various checks: Security Check (Middleware 1): Checks...
Read more

Database Approaches in .NET Core: Code-First vs Database-First Explained for Beginners

Image
Why Most Beginners Get Confused Choosing a Database Approach in .NET Core?  Beginners often confused - Here are the main reasons why this confusion happens:   1. Too Many Options, Not Enough Context It's common for beginners to feel overwhelmed by the sheer number of data access options in the .NET ecosystem. The key is to understand that these technologies are not competing to solve the same problem. Instead, they operate at different levels of abstraction to address different needs, from raw speed to developer productivity.    2. .NET Learning Curve is Already Steep ASP.NET Core has a lot: Startup, Middleware, Dependency Injection, Routing, Controllers, Services. Adding database decisions (e.g., how to scaffold models or handle migrations) is just another layer on top of all that.   3. Misleading or Fragmented Tutorials Some tutorials say “Use EF Core, it's simple!” Others say “EF is slow, ...
Read more

Dev tunnels

Image
             Dev tunnels allow you to securely expose local web services to the internet, creating a public URL that tunnels traffic directly to your development machine. This is useful for testing, collaboration, and integration with external services Uses of dev tunnel in daily development Debugging and testing on different devices Dev tunnels eliminate the need for complex network configurations when you need to test your application on a separate device. You can access your local server from a mobile phone, tablet, or another computer by simply navigating to the tunnel's public URL.  Integrating with external services and webhook  Many third-party services, like payment gateways, social media APIs, and communication platforms (e.g., Twilio), rely on webhooks to send real-time notifications to your application.  Since webhooks cannot send requests to localhost, you need a public URL to receive them.   A dev tunnel provides a secu...
Read more