AddTransient vs AddScoped vs AddSingleton: Complete Guide

In ASP.NET Core, service lifetimes determine how and when instances of services are created and shared across requests: AddTransient creates a new instance every time the service is requested, AddScoped creates one instance per client request (scope), and AddSingleton creates a single instance that lasts the entire application lifetime. The key differences lie in instance creation frequency, memory usage, thread safety, and how they handle stateful services across multiple requests.

Contents

• Understanding Service Lifetimes
• AddTransient Lifetime
• AddScoped Lifetime
• AddSingleton Lifetime
• Choosing the Right Lifetime
• Common Pitfalls and Best Practices
• Performance Considerations

Understanding Service Lifetimes

Service lifetimes in ASP.NET Core dependency injection control how instances of registered services are created and managed. Each lifetime serves different purposes and has specific characteristics that make it suitable for particular scenarios.

Service Lifetime Definition: A service lifetime determines the scope and duration for which a service instance exists and is shared across different parts of your application.

The three main service lifetimes are:

1. Transient: New instance created every time the service is requested
2. Scoped: New instance created once per client request (scope)
3. Singleton: Single instance created once and reused throughout the application lifetime

These lifetimes are registered using the AddTransient(), AddScoped(), and AddSingleton() methods respectively when configuring services in the ConfigureServices method of your Startup class or Program.cs in newer versions.

AddTransient Lifetime

Transient services are created every time they are requested from the dependency injection container. This means that if the same service is requested multiple times within the same scope, multiple instances will be created.

Characteristics

• Creation: New instance for every request
• Scope: No scope awareness
• Memory Usage: Higher (more instances created)
• Thread Safety: Generally safe (no shared state between requests)

Example Usage

// In ConfigureServices method
services.AddTransient<IEmailSender, AuthMessageSender>();

// Usage in a controller
public class HomeController : Controller
{
    private readonly IEmailSender _emailSender1;
    private readonly IEmailSender _emailSender2;
    
    public HomeController(IEmailSender emailSender1, IEmailSender emailSender2)
    {
        _emailSender1 = emailSender1;
        _emailSender2 = emailSender2;
    }
    
    public IActionResult Index()
    {
        // These will be different instances
        var instance1 = _emailSender1;
        var instance2 = _emailSender2;
    }
}

In this example, _emailSender1 and _emailSender2 will be different instances because transient services are created each time they are injected.

When to Use AddTransient

• Lightweight services with minimal initialization overhead
• Stateless services that don’t need to maintain state between calls
• Services that should never be shared between different parts of your application
• Unit testing scenarios where you want fresh instances for each test

AddScoped Lifetime

Scoped services are created once per client request (scope) and are shared within that scope. In web applications, a scope typically corresponds to a single HTTP request.

Characteristics

• Creation: New instance per scope (usually per HTTP request)
• Scope: Scope-aware (exists within the current scope)
• Memory Usage: Medium (one instance per request)
• Thread Safety: Safe within a single request, but be careful with shared state

Example Usage

// In ConfigureServices method
services.AddScoped<IEmailSender, AuthMessageSender>();

// Usage across multiple services in the same request
public class OrderService
{
    private readonly IEmailSender _emailSender;
    
    public OrderService(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }
    
    public async Task ProcessOrderAsync(Order order)
    {
        await _emailSender.SendConfirmationEmail(order);
    }
}

public class NotificationService
{
    private readonly IEmailSender _emailSender;
    
    public NotificationService(IEmailSender emailSender)
    {
        _emailSender = emailSender;
    }
    
    public async Task SendNotificationsAsync(Order order)
    {
        await _emailSender.SendNotificationEmail(order);
    }
}

// In a controller calling both services
public class OrderController : Controller
{
    private readonly OrderService _orderService;
    private readonly NotificationService _notificationService;
    
    public OrderController(OrderService orderService, NotificationService notificationService)
    {
        _orderService = orderService;
        _notificationService = notificationService;
    }
    
    public async IActionResult PlaceOrder(Order order)
    {
        await _orderService.ProcessOrderAsync(order);
        await _notificationService.SendNotificationsAsync(order);
    }
}

In this example, both OrderService and NotificationService will receive the same instance of IEmailSender because they are both within the same HTTP request scope.

When to Use AddScoped

• Database contexts (Entity Framework DbContext) - one per request to ensure proper transaction management
• Unit of work patterns - services that need to maintain state within a single operation
• Request-specific services that need to share data across multiple components during a request
• Services that need to be consistent within a single operation but isolated between different requests

AddSingleton Lifetime

Singleton services are created only once when they are first requested and then reused for all subsequent requests throughout the entire application lifetime.

Characteristics

• Creation: Single instance created once and reused
• Scope: Application-wide (no scope awareness)
• Memory Usage: Lowest (only one instance exists)
• Thread Safety: Critical consideration - must be thread-safe if used in web applications

Example Usage

// In ConfigureServices method
services.AddSingleton<IEmailSender, AuthMessageSender>();

// Application-wide configuration service
services.AddSingleton<IConfigurationService, ConfigurationService>();

// Cache service
services.AddSingleton<ICacheService, MemoryCacheService>();

Thread Safety Considerations

For singleton services in web applications, you must ensure they are thread-safe because they will be accessed by multiple concurrent requests:

public class ThreadSafeSingletonService : IThreadSafeService
{
    private readonly object _lock = new object();
    private Dictionary<string, object> _cache = new Dictionary<string, object>();
    
    public void AddToCache(string key, object value)
    {
        lock (_lock)
        {
            _cache[key] = value;
        }
    }
    
    public object GetFromCache(string key)
    {
        lock (_lock)
        {
            return _cache.TryGetValue(key, out var value) ? value : null;
        }
    }
}

When to Use AddSingleton

• Application configuration services that don’t change during runtime
• Logging services that can safely share state across requests
• Caching services designed to be shared across the entire application
• Services with expensive initialization that you want to initialize only once
• Purely stateless services that don’t maintain any request-specific data

Choosing the Right Lifetime

Selecting the appropriate service lifetime is crucial for application performance, memory usage, and correctness. Here’s a decision framework:

Decision Flowchart

Does your service maintain state that should be isolated between requests?
├── YES → Use AddScoped
│   ├── Is the state database-related? → DbContext should almost always be scoped
│   └── Does it need to be shared within a request? → Scoped is appropriate
└── NO → Consider other factors
    ├── Is the service very expensive to create? → Consider AddSingleton
    ├── Do you need the same instance across the entire app? → Use AddSingleton
    └── Do you need a fresh instance every time? → Use AddTransient

Common Service Lifetime Recommendations

Common Pitfalls and Best Practices

Common Mistakes to Avoid

1. Scoped Service in Singleton

   csharp

   // ANTI-PATTERN: This will cause issues
   services.AddSingleton<IMyService>(provider => 
   {
       var scopedService = provider.GetRequiredService<IScopedService>();
       return new MyService(scopedService);
   });
   

   This creates a captive dependency where a scoped service is captured by a singleton, causing it to live beyond its intended scope.

2. State in Singleton Services

   csharp

   // ANTI-PATTERN: Not thread-safe
   public class BadSingletonService : IMyService
   {
       private int _counter = 0;  // Shared across all requests!
       
       public void Increment()
       {
           _counter++;  // Race condition!
       }
   }
   

3. Overusing Transient Services for Heavy Objects

   csharp

   // POTENTIAL ISSUE: Expensive objects created frequently
   services.AddTransient<HeavyObject>();
   

Best Practices

1. Follow the Dependency Chain Principle: Services should not depend on services with a shorter lifetime

   • Singleton → Singleton ✓
   • Singleton → Scoped ✗ (Captive Dependency)
   • Singleton → Transient ✗ (Captive Dependency)
   • Scoped → Scoped ✓
   • Scoped → Transient ✓
   • Transient → Transient ✓

2. Use Scoped for Database Operations

   csharp

   services.AddScoped<IApplicationDbContext, ApplicationDbContext>();
   services.AddScoped<IProductRepository, ProductRepository>();
   services.AddScoped<IOrderService, OrderService>();
   

3. Consider Factory Pattern for Complex Dependencies

   csharp

   services.AddSingleton<IComplexService>(provider => 
   {
       // Create scoped dependencies here
       var scopedDependency = provider.CreateScope()
           .ServiceProvider.GetRequiredService<IScopedDependency>();
       
       return new ComplexService(scopedDependency);
   });
   

Performance Considerations

Memory Impact

• Singleton: Lowest memory footprint (one instance)
• Scoped: Medium memory footprint (one instance per concurrent request)
• Transient: Highest memory footprint (instance count = number of requests)

Creation Overhead

• Singleton: Only created once (highest initial cost, but amortized)
• Scoped: Created once per request (moderate creation cost)
• Transient: Created every time (highest cumulative creation cost)

Scalability Considerations

For high-traffic applications:

// Good for high-traffic scenarios
services.AddSingleton<IHttpClientFactory, DefaultHttpClientFactory>();

// Potentially problematic for high-traffic
services.AddTransient<ExpensiveService>();  // Creates many instances

Monitoring and Diagnostics

ASP.NET Core provides built-in diagnostics for dependency injection:

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

// Add services to the container.
builder.Services.AddControllers();

// Enable dependency injection diagnostics
builder.Services.AddDiagnostics();

var app = builder.Build();

// Use diagnostics middleware
app.UseDiagnostics();

app.MapControllers();
app.Run();

This helps identify potential issues with service lifetimes and dependency chains.

Conclusion

Understanding the differences between AddTransient, AddScoped, and AddSingleton service lifetimes is essential for building robust and performant ASP.NET Core applications. Here are the key takeaways:

1. Use AddTransient for lightweight, stateless services that need fresh instances each time they’re requested, such as validation services or utilities with minimal initialization overhead.

2. Use AddScoped for services that need to maintain state within a single request but be isolated between different requests, particularly database contexts (DbContext), repositories, and business logic services.

3. Use AddSingleton for application-wide services that are thread-safe and don’t maintain request-specific state, such as configuration services, logging, and caching mechanisms.

4. Be cautious with captive dependencies - never inject scoped or transient services into singletons, as this can cause unexpected behavior and memory leaks.

5. Consider performance implications - singleton services offer the best performance for frequently accessed services, while transient services can impact performance if used for expensive objects.

By carefully choosing the appropriate service lifetime for each dependency, you’ll build applications that are more maintainable, performant, and less prone to concurrency-related issues.

Sources

1. Microsoft Learn - Service lifetimes in dependency injection
2. ASP.NET Core Documentation - Dependency injection
3. Stack Overflow - Difference between AddTransient, AddScoped and AddSingleton
4. Microsoft Learn - Registering scoped services in singleton
5. GitHub - ASP.NET Core source code - ServiceLifetime enum