DEV Community: Abhinaw

5 ASP.NET Core DI Scope Mistakes That Will Crash Your App

Abhinaw — Fri, 10 Oct 2025 07:03:55 +0000

Most of us treat dependency injection scopes like a checkbox: pick Singleton, Scoped, or Transient and move on. That confidence lasts until a 3 AM production crash, and you're staring at an ObjectDisposedException.

I learned this the hard way. Let's walk through the five most common DI scope mistakes I see in code reviews so you can avoid them.

1. Registering `DbContext` as Singleton

This is the fastest way to corrupt data. DbContext is not thread-safe and holds tracked entities. As a singleton, it creates massive memory leaks and concurrency bugs.

❌ The Mistake

// DON'T DO THIS
services.AddSingleton<AppDbContext>();

✅ The Fix
Always register DbContext as scoped. This is the default behavior and ensures one instance per request.

// CORRECT
services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

2. Injecting Scoped Services into Singletons

A singleton lives forever; a scoped service dies with the request. Trying to inject a scoped service (like a repository using DbContext) into a singleton will cause an InvalidOperationException.

❌ The Mistake

public class MySingletonService
{
    // You can't inject a scoped service here!
    public MySingletonService(IUserRepository userRepo) { ... }
}

services.AddSingleton<MySingletonService>();
services.AddScoped<IUserRepository, UserRepository>();

✅ The Fix
If you must access a scoped service from a singleton, inject IServiceScopeFactory and create a scope manually.

public class MySingletonService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public async Task DoWorkAsync()
    {
        using var scope = _scopeFactory.CreateScope();
        var repo = scope.ServiceProvider.GetRequiredService<IUserRepository>();
        // ... use the repo
    }
}

3. Forgetting Scopes in Background Services

BackgroundService instances are singletons and run outside the request pipeline, so there's no automatic scope. Injecting DbContext directly will cause it to live forever, leading to memory leaks.

❌ The Mistake

public class NotificationService : BackgroundService
{
    private readonly AppDbContext _dbContext; // WRONG! Lives forever.

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

    protected override async Task ExecuteAsync(CancellationToken token)
    {
        // This uses the same DbContext instance for days...
        var items = await _dbContext.Notifications.ToListAsync();
    }
}

✅ The Fix
Use IServiceScopeFactory to create a new scope for each unit of work inside your ExecuteAsync loop.

public class NotificationService : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public NotificationService(IServiceScopeFactory scopeFactory) { ... }

    protected override async Task ExecuteAsync(CancellationToken token)
    {
        while (!token.IsCancellationRequested)
        {
            using (var scope = _scopeFactory.CreateScope())
            {
                var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
                // DbContext is disposed correctly after each loop
                var items = await dbContext.Notifications.ToListAsync(token);
            }
            await Task.Delay(TimeSpan.FromMinutes(5), token);
        }
    }
}

4. Misunderstanding Middleware Scopes

Middleware classes are singletons—created once for the application's lifetime. If you inject a scoped service into the constructor, you capture the service from the first request and reuse it for all subsequent requests, leading to data bleeding between users.

❌ The Mistake

public class TenantMiddleware
{
    private readonly ITenantService _tenantService; // Scoped, but captured!

    // Constructor injection captures the service
    public TenantMiddleware(RequestDelegate next, ITenantService tenantService)
    {
        _tenantService = tenantService;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // Using the same tenant service instance for every request!
        await _tenantService.DoWorkAsync();
        await _next(context);
    }
}

✅ The Fix
Inject scoped services directly into the InvokeAsync method. The DI container resolves these dependencies per-request.

public class TenantMiddleware
{
    public TenantMiddleware(RequestDelegate next) { ... }

    // Scoped services are injected here, per-request
    public async Task InvokeAsync(HttpContext context, ITenantService tenantService)
    {
        await tenantService.DoWorkAsync();
        await _next(context);
    }
}

5. Overusing Transient for Heavy Objects

Transient creates a new instance every single time an object is requested. This is fine for lightweight, stateless services, but it's a performance killer for heavy objects like HttpClient (can cause socket exhaustion) or compiled regex patterns.

❌ The Mistake

// BAD: Creates a new client every time, can lead to socket exhaustion
services.AddTransient<HttpClient>();

✅ The Fix
Use AddHttpClient for HttpClient management and register other heavy, stateless services as Singleton.

// GOOD: Manages HttpClient lifecycle and connection pooling
services.AddHttpClient<MyApiService>();

// GOOD: Compile once, reuse everywhere
services.AddSingleton<IRegexValidator>(sp => 
    new RegexValidator(MyCompiledRegex));

Quick Checklist

Singleton: For stateless, thread-safe services (e.g., loggers, configuration).
Scoped: For services that need to maintain state within a single request (e.g., DbContext, Unit of Work).
Transient: For lightweight, stateless services that are cheap to create.

Take 5 minutes to audit your Program.cs file. A quick check now can save you a major production headache later.

Happy coding!

Applying OOP in ASP.NET Core

Abhinaw — Mon, 01 Sep 2025 00:30:00 +0000

Most OOP articles throw around the same tired examples: animals, shapes, and bank accounts. While these illustrate concepts, they don't show you how OOP principles actually manifest in production ASP.NET Core applications.

After building web APIs for the past several years, I've learned that understanding OOP in the context of controllers, services, and domain models is what separates junior developers from those who can architect maintainable systems.

Let's walk through the four pillars as they appear in real codebases, with the messiness and trade-offs included.

Encapsulation: Moving Beyond Property Getters and Setters

Encapsulation isn't just about making fields private, it's about hiding behavior and controlling how your objects change state. I see this violated constantly in controllers that directly manipulate domain objects.

Here's a controller I inherited that violated encapsulation:

[HttpPost("users")]
public async Task<IActionResult> CreateUser(CreateUserRequest request)
{
    // Validation scattered everywhere
    if (string.IsNullOrEmpty(request.Email) || !request.Email.Contains("@"))
        return BadRequest("Invalid email");

    if (request.Password.Length < 8)
        return BadRequest("Password too short");

    var user = new User();
    user.Email = request.Email;
    user.Password = BCrypt.Net.BCrypt.HashPassword(request.Password);
    user.CreatedAt = DateTime.UtcNow;
    user.IsActive = true;

    await _userRepository.SaveAsync(user);
    return Ok();
}

After refactoring with proper encapsulation:

[HttpPost("users")]
public async Task<IActionResult> CreateUser(CreateUserRequest request)
{
    var userResult = User.Create(request.Email, request.Password);
    if (!userResult.IsSuccess)
        return BadRequest(userResult.Error);

    await _userRepository.SaveAsync(userResult.Value);
    return Ok();
}

public class User
{
    private User() { } // Force creation through factory method

    public string Email { get; private set; }
    public string PasswordHash { get; private set; }
    public DateTime CreatedAt { get; private set; }
    public bool IsActive { get; private set; }

    public static Result<User> Create(string email, string password)
    {
        if (string.IsNullOrEmpty(email) || !email.Contains("@"))
            return Result<User>.Failure("Invalid email format");

        if (password.Length < 8)
            return Result<User>.Failure("Password must be at least 8 characters");

        return Result<User>.Success(new User
        {
            Email = email,
            PasswordHash = BCrypt.Net.BCrypt.HashPassword(password),
            CreatedAt = DateTime.UtcNow,
            IsActive = true
        }
});
    }
}

// Result<T> is a simple success/failure wrapper that avoids throwing exceptions for business rule violations
public class Result<T>
{
    public bool IsSuccess { get; private set; }
    public T Value { get; private set; }
    public string Error { get; private set; }

    public static Result<T> Success(T value) => new() { IsSuccess = true, Value = value };
    public static Result<T> Failure(string error) => new() { IsSuccess = false, Error = error };
}
}

The domain object now controls its own creation and validation. The controller can't accidentally create invalid users, and the business rules live where they belong.

You can read my detailed post on encapsulation best practices for more insights.

Now let's look at how abstraction solves another common pain point in web applications.

Abstraction: Interfaces That Actually Matter

Abstraction in ASP.NET Core shines when you need to swap implementations or mock dependencies. I learned this the hard way when a project needed to switch from Azure Blob Storage to AWS S3 midway through development.

Instead of this tightly coupled nightmare:

public class DocumentController : ControllerBase
{
    private readonly BlobServiceClient _blobClient;

    [HttpPost("upload")]
    public async Task<IActionResult> Upload(IFormFile file)
    {
        var containerClient = _blobClient.GetBlobContainerClient("documents");
        var blobClient = containerClient.GetBlobClient(file.FileName);

        using var stream = file.OpenReadStream();
        await blobClient.UploadAsync(stream, overwrite: true);

        return Ok(new { Url = blobClient.Uri.ToString() });
    }
}

I created an abstraction that saved the project:

public interface IStorageService
{
    Task<string> UploadAsync(Stream content, string fileName);
    Task<Stream> DownloadAsync(string fileName);
    Task DeleteAsync(string fileName);
}

public class DocumentController : ControllerBase
{
    private readonly IStorageService _storageService;

    [HttpPost("upload")]
    public async Task<IActionResult> Upload(IFormFile file)
    {
        using var stream = file.OpenReadStream();
        var result = await _storageService.UploadAsync(stream, file.FileName);
        return Ok(new { Url = result });
    }
}

Now I can inject AzureBlobStorageService or S3StorageService implementations without touching the controller. More importantly, my integration tests use InMemoryStorageService instead of hitting real cloud services.

Remember though: not every dependency needs an interface. Over-abstracting simple, stable dependencies like DateTime.UtcNow or basic string operations creates unnecessary complexity. Focus abstraction on volatile dependencies, external services, file systems, or anything that changes between environments.

If you're deciding between abstract classes and interfaces, I've covered this in detail in C#: Abstract Class or Interface? 10 Questions to Ask. I also explained why in most cases you should prefer interfaces over abstract classes in C#, especially when building flexible, testable, and maintainable code.

This brings us to inheritance, which many developers reach for too quickly when trying to share code.

Inheritance: When It Becomes a Problem

Early in my career, I thought inheritance was the solution to code reuse. I created elaborate controller hierarchies that seemed elegant at first:

public abstract class BaseController : ControllerBase
{
    protected readonly ILogger _logger;
    protected readonly IUserService _userService;

    protected BaseController(ILogger logger, IUserService userService)
    {
        _logger = logger;
        _userService = userService;
    }

    protected async Task<User> GetCurrentUser()
    {
        var userId = User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        return await _userService.GetByIdAsync(userId);
    }
}

public class OrderController : BaseController
{
    private readonly IOrderService _orderService;

    public OrderController(ILogger logger, IUserService userService, IOrderService orderService) 
        : base(logger, userService)
    {
        _orderService = orderService;
    }
}

This inheritance chain became unmaintainable when controllers needed different dependencies or when the base class grew too many responsibilities. The dependency injection container also struggled with the constructor chains, making unit tests painful to set up and leading to brittle constructor hierarchies.

I refactored to composition using the mediator pattern:

public class OrderController : ControllerBase
{
    private readonly IMediator _mediator;

    public OrderController(IMediator mediator)
    {
        _mediator = mediator;
    }

    [HttpGet("{id}")]
    public async Task<IActionResult> GetOrder(int id)
    {
        var query = new GetOrderQuery(id, GetCurrentUserId());
        var result = await _mediator.Send(query);

        if (!result.IsSuccess)
            return BadRequest(result.Error);

        return Ok(result.Value);
    }

    private string GetCurrentUserId() => User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
}

Each handler now has only the dependencies it needs, and the controllers stay thin and focused.

Inheritance is powerful, but overusing it can lead to fragile hierarchies. In fact, in many cases composition is the better design choice. I've written a detailed guide on Composition Over Inheritance in C# that shows how to write more flexible and maintainable code.

While composition solved the inheritance problem, we still had branching logic scattered throughout the codebase. That's where polymorphism becomes invaluable.

Polymorphism: Strategy Pattern in Action

Switch statements are code smells that scream for polymorphism. I encountered this in a notification system that grew organically:

public class NotificationService
{
    public async Task SendAsync(NotificationRequest request)
    {
        switch (request.Type)
        {
            case NotificationType.Email:
                // Email sending logic
                var emailClient = new SmtpClient();
                await emailClient.SendMailAsync(request.Recipient, request.Subject, request.Message);
                break;

            case NotificationType.SMS:
                // SMS logic
                var smsClient = new TwilioClient();
                await smsClient.SendAsync(request.Recipient, request.Message);
                break;

            case NotificationType.Push:
                // Push notification logic
                var pushService = new FirebaseService();
                await pushService.SendAsync(request.Recipient, request.Message);
                break;

            default:
                throw new NotSupportedException($"Notification type {request.Type} not supported");
        }
    }
}

The refactored version uses polymorphism through the strategy pattern:

public interface INotificationStrategy
{
    NotificationType Type { get; }
    Task SendAsync(string recipient, string subject, string message);
}

public class NotificationService
{
    private readonly Dictionary<NotificationType, INotificationStrategy> _strategies;
    private readonly ILogger<NotificationService> _logger;

    public NotificationService(IEnumerable<INotificationStrategy> strategies, ILogger<NotificationService> logger)
    {
        _strategies = strategies.ToDictionary(s => s.Type, s => s);
        _logger = logger;
    }

    public async Task<Result> SendAsync(NotificationRequest request)
    {
        if (!_strategies.TryGetValue(request.Type, out var strategy))
        {
            _logger.LogWarning("Unsupported notification type: {NotificationType}", request.Type);
            return Result.Failure($"Notification type {request.Type} not supported");
        }

        try
        {
            await strategy.SendAsync(request.Recipient, request.Subject, request.Message);
            return Result.Success();
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Failed to send {NotificationType} notification to {Recipient}", 
                request.Type, request.Recipient);
            return Result.Failure("Failed to send notification");
        }
    }
    }
}

Adding new notification types now requires only implementing the interface and registering it with DI. No more modifying the core service. The production-ready version handles logging and graceful failure instead of throwing exceptions up the stack.

Polymorphism isn't just about virtual methods in classes, it's the foundation of many design patterns. In fact, patterns like Template Method, Strategy, and Visitor rely on polymorphism to keep code flexible. I've covered these in detail in Polymorphism in C#: How Template Method, Strategy, and Visitor Patterns Make Your Code Flexible.

Conclusion

OOP isn't a silver bullet, it's a toolset for managing complexity. In ASP.NET Core applications, these principles help you build systems that are readable, testable, and maintainable over time. Encapsulation keeps your domain logic consistent, abstraction enables flexibility and testing, composition beats inheritance for reusability, and polymorphism eliminates branching logic.

The key is knowing when to apply each principle. Not every class needs elaborate abstractions, and not every conditional deserves the strategy pattern. Focus on the pain points: where your code is hard to test, where changes ripple through multiple files, or where adding features requires modifying existing code. That's where OOP principles provide the most value.

After years of building and maintaining web APIs, I've learned that good OOP isn't about following rules religiously, it's about creating code that the next developer (including future you) can understand and extend without fear.

SOLID Principles Simplified: Cheatsheet + Interview Guide

Abhinaw — Thu, 28 Aug 2025 00:00:00 +0000

Every developer can recite what SOLID stands for, but in interviews and real-world reviews, it's the practical application that matters. Here’s my no-fluff cheatsheet with code smells, fixes, and analogies I use in reviews.

Want the PDF version? Click here to download

S: Single Responsibility Principle (SRP)

Real Meaning: One reason to change, not one "thing" it does.
Why It Matters: Avoids "God classes" that block clean PRs & slow refactoring.
Personal Analogy: "If you can't give a clean commit message for the change, it's violating SRP."
Code Smell: Method/class summary has multiple and/or.
Actionable: Before adding a method, ask: "Is this a different concern?"
Read more on SRP
Short link: bytecrafted.dev/solid-srp

// Bad: Class doing too much (data + printing)
public class Report {
    public string Content { get; set; }
    public void Print() => Console.WriteLine(Content);
}

// Good: Split responsibilities
public class Report { public string Content { get; set; } }
public class ReportPrinter 
{ 
    public void Print(Report r) => Console.WriteLine(r.Content); 
}

O: Open/Closed Principle (OCP)

Real Meaning: Add features by extension, not by editing old code.
Why It Matters: Keeps legacy code stable; new business rules plug in cleanly.
Personal Analogy: "If a new requirement means touching brittle switch statements, you're not OCP."
Code Smell: Growing switch/if chains for types or behaviors.
Actionable: When adding a rule, prefer new handler/class over changing the old one.
Read more on OCP
Short link: bytecrafted.dev/solid-ocp

// Bad: Must edit method every time a new shape is added
public double Area(object shape) {
    if (shape is Circle c) return Math.PI * c.Radius * c.Radius;
    if (shape is Square s) return s.Side * s.Side;
    return 0;
}

// Good: Add new shapes by extension
public interface IShape { double Area(); }
public class Circle : IShape 
{
  public double Radius { get; set; }
  public double Area() => Math.PI * Radius * Radius; 
}
public class Square : IShape 
{
  public double Side { get; set; } 
  public double Area() => Side * Side; 
}

L: Liskov Substitution Principle (LSP)

Real Meaning: Subtypes must behave as expected, no surprises for callers.
Why It Matters: Swapping implementations shouldn't break existing tests or runtime logic.
Personal Analogy: "If a subclass throws where the base returns null, that's an LSP landmine."
Code Smell: Derived classes override with different exceptions, parameters, or semantics.
Actionable: Run parent class tests on every subclass; look for broken guarantees.
Read more on LSP
Short link: bytecrafted.dev/solid-lsp

// Bad: Subclass breaks expectations
public class Bird { public virtual void Fly() { } }
public class Penguin : Bird 
{
   public override void Fly() => throw new NotSupportedException(); 
}

// Good: Refactor hierarchy
public abstract class Bird { }
public class FlyingBird : Bird { public void Fly() { /* ... */ } }
public class Penguin : Bird { public void Swim() { /* ... */ } }

I: Interface Segregation Principle (ISP)

Real Meaning: Small, client-focused interfaces, never force unused methods.
Why It Matters: Reduces coupling, makes mocks/tests trivial, avoids NotSupportedException landmines.
Personal Analogy: "If your interface summary needs bullet points, it's already too fat."
Code Smell: Implementations with empty or throw NotSupportedException methods.
Actionable: Extract groups of related methods into separate interfaces as soon as a client skips one.
Read more on ISP
Short link: bytecrafted.dev/solid-isp

// Bad: Fat interface forces unused methods
public interface IMachine {
    void Print();
    void Scan();
    void Fax();
}

public class BasicPrinter : IMachine {
    public void Print() { }
    public void Scan() => throw new NotSupportedException();
    public void Fax() => throw new NotSupportedException();
}

// Good: Split into smaller interfaces
public interface IPrinter { void Print(); }
public interface IScanner { void Scan(); }

public class BasicPrinter : IPrinter {
    public void Print() { }
}

D: Dependency Inversion Principle (DIP)

Real Meaning: Depend on abstractions, not concrete implementations, flip the usual control.
Why It Matters: Makes business logic testable, swappable, and free of infrastructure glue.
Personal Analogy: "If you see new SqlRepo() in a service, that's DIP going up in flames."
Code Smell: Direct instantiation of dependencies inside business logic.
Actionable: Use constructor injection for every external dependency; mock in tests, swap in production.
Read more on DIP
Short link: bytecrafted.dev/solid-dip

// Bad: High-level depends on low-level directly
public class ReportService {
    private readonly SqlReportRepo _repo = new SqlReportRepo();
}

// Good: Depend on abstraction, inject implementation
public interface IReportRepo { /* ... */ }
public class SqlReportRepo : IReportRepo { /* ... */ }

public class ReportService {
    private readonly IReportRepo _repo;
    public ReportService(IReportRepo repo) { _repo = repo; }
}

Read full series: bytecrafted.dev/series/solid.

3 Signs Your Code Needs Middleware - ASP.NET Core

Abhinaw — Wed, 27 Aug 2025 05:39:55 +0000

If your services are bloated or you're duplicating logic across controllers, middleware might be the extension point you actually need. Many developers reach for filters or services first, when middleware would've been faster, simpler, and more maintainable.

(This article was originally published on my blog: bytecrafted.dev)

Sign #1: Repeating Code Across Controllers?

The Problem: You're seeing identical logging, CORS handling, header validation, or request sanitization code across multiple controllers.

// Instead of this in every controller
[HttpGet]
public async Task<IActionResult> GetUsers()
{
    _logger.LogInformation("Request received from {IP}", Request.HttpContext.Connection.RemoteIpAddress);

    if (!Request.Headers.ContainsKey("X-API-Version"))
        return BadRequest("API version required");

    // actual logic here
}

Why Middleware Helps: Middleware centralizes repeated logic at the pipeline level, executing once before requests reach your controllers. This reduces code duplication and improves performance by handling cross-cutting concerns upstream.

Sign #2: You're Modifying Requests or Responses Frequently

The Problem: Controllers are injecting headers, rewriting URLs, or transforming request bodies before processing business logic.

Why Middleware Helps: ASP.NET Core middleware is purpose-built for request/response interception and transformation. Moving this logic to middleware keeps your action methods focused on business logic while handling framework concerns efficiently.

public class TenantResolutionMiddleware
{
    public async Task InvokeAsync(HttpContext context, RequestDelegate next)
    {
        var tenantId = context.Request.Headers["X-Tenant-ID"].FirstOrDefault();
        context.Items["TenantId"] = tenantId ?? "default";

        await next(context);
    }
}

Sign #3: Your Services Depend on HttpContext

The Problem: Business services are injecting HttpContext, accessing Request.Headers, or checking environment details directly.

Why Middleware Helps: Middleware isolates framework concerns from business logic. Extract tenant information, authentication tokens, or culture settings in middleware, then pass clean data to your services through scoped services or HttpContext.Items, keeping services clean.

This pattern improves testability, your services no longer need mock HTTP contexts for unit tests.

Performance Impact

Based on profiling real production apps handling 10,000+ requests per minute, moving cross-cutting concerns to middleware typically reduces controller execution time by 15-20% and simplifies debugging through centralized logging.

Bottom Line: Middleware isn't just a pipeline detail, it's an architectural tool for isolating cross-cutting concerns and maintaining clean, testable code.

Refactoring Messy Code: High Cohesion and Low Coupling

Abhinaw — Thu, 14 Aug 2025 06:38:39 +0000

After 10+ years building enterprise applications, I've learned that two principles guide every successful refactoring: high cohesion and low coupling.

Cohesion = Does this class have a clear, single purpose?

Coupling = How many parts break when I change this?

Spotting Low Cohesion

Here's the mess I typically inherit:

class Student {
    name: string;
    grade: number;

    constructor(name: string, grade: number) {
        this.name = name;
        this.grade = grade;
    }

    getGPA(): number {
        return this.grade / 100;
    }

    // This shouldn't be here!
    save(): void {
        console.log(`Saving ${this.name} to database...`);
    }

    // Neither should this!
    sendEmail(): void {
        console.log(`Sending email to ${this.name}...`);
    }
}

This violates Single Responsibility Principle by mixing student data, database operations, and communication logic.

My Refactoring Approach

I break it into focused classes:

// High cohesion - focused on student data only
class Student {
    constructor(
        public readonly name: string,
        private grade: number
    ) {}

    getGPA(): number {
        return this.grade / 100;
    }
}

// Handles database operations
class StudentRepository {
    saveStudent(student: Student): void {
        // Database logic here
    }
}

// Manages communications  
class StudentNotifier {
    sendEmailToStudent(student: Student): void {
        // Email logic here
    }
}

Reducing Coupling with Dependency Injection

Instead of tight coupling:

public class Order
{
    public void Ship()
    {
        // Tightly coupled - creates concrete dependencies
        var shipper = new UPSShipper();
        shipper.Ship(this);
    }
}

Use interfaces and injection:

public class OrderProcessor
{
    private readonly IShippingProvider _shippingProvider;

    public OrderProcessor(IShippingProvider shippingProvider)
    {
        _shippingProvider = shippingProvider;
    }

    public void ProcessOrder(Order order)
    {
        _shippingProvider.ShipOrder(order);
    }
}

public interface IShippingProvider
{
    void ShipOrder(Order order);
}

Angular Example

These principles work perfectly in Angular:

@Injectable({ providedIn: 'root' })
export class UserService {
    constructor(private http: HttpClient) {}

    getUser(id: string): Observable<User> {
        return this.http.get<User>(`/api/users/${id}`);
    }
}

@Component({
    selector: 'app-user-profile',
    template: '...'
})
export class UserProfileComponent {
    user$ = signal<User | null>(null);

    constructor(
        private userService: UserService,
        private notificationService: INotificationService
    ) {}

    async saveUser(user: User): Promise<void> {
        try {
            const updated = await this.userService.updateUser(user);
            this.user$.set(updated);
            this.notificationService.showSuccess('Saved!');
        } catch {
            this.notificationService.showError('Failed!');
        }
    }
}

Quick Quality Check

Ask yourself:

Can I describe this class's purpose in one sentence? (cohesion test)
How many classes break when requirements change? (coupling test)
How much setup do my unit tests need? (both tests)

The Payoff

Systems built with these principles are:

Easier to maintain - changes stay isolated
Simpler to test - focused classes, mockable dependencies
More flexible - swap implementations without breaking things
Less buggy - failures don't cascade

Start applying this in your next feature. Your future self will thank you.

Originally published on my blog with more detailed examples and implementation strategies.

Stop Adding Async to Everything - It's Making Your C# Code Slower

Abhinaw — Thu, 07 Aug 2025 07:02:00 +0000

I used to be that developer who added async and await to every method. Database calls, file operations, even simple calculations. I thought I was writing "modern" C# code.

I was wrong.

After benchmarking real applications, I discovered that async isn't the performance boost most developers think it is. In fact, it often makes individual operations slower while adding unnecessary complexity.

(This article was originally published on my blog: bytecrafted.dev.)

The Big Misconception: Scalability != Speed

Here's what I wish someone had told me earlier:

Async improves scalability, not speed. It helps your system handle more concurrent users without blocking threads, but it usually doesn't make individual operations faster.

Think of it this way:

Synchronous code: Serve 50 people quickly, but only 50 at a time
Async code: Serve 5000 people simultaneously, but each might wait a bit longer

The Numbers Don't Lie

I ran actual benchmarks on .NET 8. Here's what I found:

Simple method calls: Async was 72x slower than sync (1,435ns vs 19.9ns)
CPU-bound calculations: Async with Task.Run was 60% slower with 10x more memory allocations
Database queries: Async added 5% overhead even for simple EF Core operations

// This adds 60% overhead and 10x memory allocations
public async Task<decimal> CalculateTotalAsync(List<OrderItem> items)
{
    return await Task.Run(() => items.Sum(x => x.Price * x.Quantity));
}

// Just do this - 60% faster
public decimal CalculateTotal(List<OrderItem> items)
{
    return items.Sum(x => x.Price * x.Quantity);
}

When Async Actually Helps

Don't get me wrong - async is powerful when used correctly. Use it for:

Remote HTTP calls (third-party APIs, microservices)
Cloud storage operations (S3, Azure Blob, large file uploads)
Message queue operations (Service Bus, RabbitMQ)
High-concurrency scenarios (1000+ simultaneous users)

My Simple Rule: L.A.T.E.

Before making a method async, ask: Is it L.A.T.E.?

Latency-bound (waiting on slow network/disk)
Awaiting remote I/O (APIs, cloud services)
Thread pool constrained (high concurrent load)
Expensive to block (user-facing bottlenecks)

If none of these apply, start synchronous.

The Real Problem: Async Contamination

Sometimes libraries force async on you. EF Core's FirstOrDefaultAsync(), HttpClient.SendAsync(), and cloud SDKs are async-first or async-only.

Solution: Keep async at your application boundaries (controllers, repositories) but keep your domain logic synchronous. Async should be an infrastructure concern, not a business logic concern.

Key Takeaway

Most enterprise applications don't need async everywhere - they need it strategically. Profile your application, identify real bottlenecks, then apply async to solve actual concurrency problems.

I've seen more bugs from async overuse than from sync bottlenecks. Start simple, optimize when you have proof there's a need.

Read the full deep-dive with complete benchmarks and real-world examples: Why Async Can Be Slower in Real Projects?

What's your experience with async overuse? Have you seen performance regressions from unnecessary async/await? Share your stories in the comments!

HTTP Logging Middleware Tips That Actually Work in ASP.NET Core

Abhinaw — Tue, 29 Jul 2025 04:30:00 +0000

Ever tried logging HTTP request bodies in ASP.NET Core and ended up with broken pipelines or empty responses? You're not alone. HTTP logging middleware seems straightforward until you hit the gotchas that make everything fall apart.

I've collected 13 practical tips that solve the real problems developers encounter when implementing HTTP logging middleware. Here's what actually works in production.

The Big 3 Issues (And How to Fix Them)

1. Request Body Disappears After Reading

// The fix: EnableBuffering() + reset position
context.Request.EnableBuffering();
var body = await new StreamReader(context.Request.Body).ReadToEndAsync();
context.Request.Body.Position = 0; // Critical!

2. Response Bodies Don't Reach Clients

// The fix: Swap streams temporarily
var originalBody = context.Response.Body;
using var memStream = new MemoryStream();
context.Response.Body = memStream;
await next(context);
// Copy back to original stream
memStream.Seek(0, SeekOrigin.Begin);
await memStream.CopyToAsync(originalBody);
context.Response.Body = originalBody;

3. Performance Tanks with Large Payloads

// The fix: Size limits and conditional logging
if (context.Request.ContentLength > 1024) 
{
    _logger.LogInformation("Request too large, skipping body log");
    await next(context);
    return;
}

Quick Wins You Can Implement Today

Filter Noise from Health Checks:

var path = context.Request.Path.Value?.ToLower();
if (path?.StartsWith("/health") == true || path?.StartsWith("/metrics") == true)
{
    await next(context);
    return;
}

Redact Sensitive Data:

private string RedactSensitiveFields(string json)
{
    return Regex.Replace(json, @"""(password|token|ssn)""\s*:\s*""[^""]*""", 
                        @"""$1"":""***""", RegexOptions.IgnoreCase);
}

Skip Binary Content:

var contentType = context.Request.ContentType?.ToLower();
if (contentType?.Contains("multipart/form-data") == true ||
    contentType?.Contains("image/") == true)
{
    await next(context);
    return;
}

Built-in vs Custom: When to Choose What

Feature	Built-in HttpLogging	Custom Middleware
Setup	2 lines of code	~50 lines
Filtering	Basic	Full control
Performance	Good	Optimizable
Sensitive data	Basic redaction	Custom logic

Use built-in for: Simple logging, quick debugging
Use custom for: Production apps, compliance requirements, performance optimization

Performance Tips That Matter

Size limits: Cap at 1KB for dev, 10KB max for production
Sampling: Log 10% of requests in production instead of 100%
Async operations: Always use ReadToEndAsync() and CopyToAsync()
Path filtering: Skip static files, health checks, and metrics endpoints
Memory efficiency: Use PipeReader and Span<T> for zero-allocation processing

Clean Extension Method Pattern

// Registration
builder.Services.AddHttpLogging(options =>
{
    options.MaxBodySize = 2048;
    options.SamplingRate = 0.1; // 10% in production
    options.SkipPaths = new[] { "/health", "/swagger" };
});

// Usage
app.UseHttpLogging();

Production Gotchas to Avoid

Never log authentication endpoints - passwords and tokens leak
Always reset stream positions - downstream middleware breaks otherwise
Set memory limits - large uploads can crash your app
Use structured logging - makes debugging and monitoring easier
Handle exceptions gracefully - logging shouldn't break request processing

Where to Send Your Logs

Development: Console logging for immediate feedback
Staging: File logging for integration debugging
Production: External services (Seq, ELK) with file backup

The key is matching your logging strategy to your monitoring needs.

Want the complete implementation with all 13 tips, advanced filtering, and production-ready code? Check out my full guide: ASP.NET Core HTTP Logging Middleware: 13 Practical Micro Tips

What's your biggest HTTP logging challenge? Drop a comment - I'd love to help troubleshoot specific scenarios.

P.S. - Always test your logging middleware in a staging environment that mirrors production load. What works with 10 requests might fail with 10,000.

Stop Your SQL JOINs from Crawling: A Quick Index Fix

Abhinaw — Mon, 28 Jul 2025 04:30:00 +0000

Ever watched a perfectly fine query turn into a 30-second nightmare in production? Yeah, me too. Usually, it's JOIN operations hitting tables without proper indexes, forcing full table scans instead of quick lookups.

I recently tackled this exact problem with an e-commerce query that was killing performance. Here's what I learned and how you can fix it fast.

The Problem Query

SELECT c.customer_name, o.order_date, p.product_name, oi.quantity
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date >= '2024-01-01'
    AND p.category = 'Electronics'
    AND c.region = 'North America';

This innocent-looking query was scanning entire tables for every JOIN. With 50K orders and 150K order items, that's a lot of wasted work.

The Index Strategy That Actually Works

The magic is in composite indexes with the right column order: filter columns first, JOIN columns second.

-- Strategic indexes that match our query pattern
CREATE INDEX idx_customers_region_id ON customers (region, customer_id);
CREATE INDEX idx_orders_date_customer ON orders (order_date, customer_id, order_id);
CREATE INDEX idx_products_category_id ON products (category, product_id);
CREATE INDEX idx_order_items_order_product ON order_items (order_id, product_id);

Results That Matter

Before: 366ms execution time, full table scans everywhere
After: 65ms execution time, clean index seeks
Performance gain: 82% faster with proper indexes

The execution plan switched from expensive Hash Joins and table scans to efficient Index Seeks and Nested Loops.

Common Mistakes That Kill Performance

Functions on indexed columns:

-- Bad: WHERE YEAR(order_date) = 2024
-- Good: WHERE order_date >= '2024-01-01'

Wrong index column order:

-- Wrong: (product_id, category) for category filters
-- Right: (category, product_id) - filter column first

Data type mismatches:

-- Bad: WHERE customer_id = '123' (string vs int)
-- Good: WHERE customer_id = 123

Pro Tips for Production

Start with the most selective filter - reorder your JOINs to hit filtered tables first
Use covering indexes for frequently selected columns
Monitor index usage - unused indexes waste space and slow writes
Check execution plans regularly - they tell you exactly what's happening

Quick Wins You Can Implement Today

Identify your slowest JOIN-heavy queries
Check if WHERE clause columns have indexes
Create composite indexes: filter columns → JOIN columns
Test with real data volumes, not dev datasets

The difference between a frustrated user and a happy one often comes down to having the right indexes. Your 10-second query can become sub-second with strategic indexing.

Want the full deep-dive with execution plans, test data setup, and advanced optimization techniques? Check out my complete guide: SQL Query Optimization in Action: Indexing and Execution Plan Deep Dive

What's your biggest JOIN performance headache? Drop a comment - I'd love to help troubleshoot.

P.S. - Always test index changes in a staging environment first. Indexes speed up reads but can slow down writes.

11 EF Core Performance Mistakes That Will Kill Your App

Abhinaw — Sat, 26 Jul 2025 04:30:00 +0000

Your app works fine in development with 100 test records. Then production hits with real data, and suddenly everything crawls. Sound familiar?

I've debugged enough slow .NET apps to know the real culprit: bad EF Core queries. Here are the 11 most common mistakes I see in production code.

For detailed code examples and performance benchmarks, check out the full deep-dive guide.

1. The N+1 Query Problem

Bad: Load orders, then access order.Customer.Name in a loop = 1,001 database calls
Fix: Use Include(o => o.Customer) or projection with Select()

I've written a detailed breakdown of N+1 queries and Include vs SplitQuery if you want to dive deeper.

2. Premature ToList()

Bad: _context.Products.ToList().Where(p => p.Price > 100) fetches everything first
Fix: Build your query completely, then call ToList() once

3. Client-Side Evaluation

Bad: Using Func<T, bool> forces filtering in memory after downloading all data
Fix: Use Expression<Func<T, bool>> to keep filtering in SQL

4. Over-Fetching Data

Bad: Loading entire entities when you only need Name and Price
Fix: Use projection: Select(p => new { p.Name, p.Price })

5. Missing Indexes

Bad: Querying without indexes = full table scans
Fix: Add indexes for columns in WHERE, ORDER BY, and JOIN clauses

6. Unnecessary Change Tracking

Bad: EF Core tracks entities you'll never update, wasting memory
Fix: Use AsNoTracking() for read-only queries

7. Lazy Loading Surprises

Bad: Accessing navigation properties triggers hidden database calls
Fix: Explicitly load related data with Include() or turn lazy loading off

8. Poor DbContext Lifetime

Bad: Creating new contexts for every operation or keeping one alive forever
Fix: Use scoped lifetime in DI - one context per web request

9. Non-Compiled Repeated Queries

Bad: EF Core rebuilds query plans for identical queries
Fix: Use EF.CompileAsyncQuery() for frequently executed queries

10. Individual Operations

Bad: Calling SaveChanges() in a loop
Fix: Add all entities, then call SaveChanges() once

11. No Performance Monitoring

Bad: Flying blind without seeing generated SQL
Fix: Enable query logging and use ToQueryString() for debugging

The Real Cost

I've seen these mistakes turn 50ms queries into 5-second nightmares. One N+1 problem in production generated 2,000+ database calls for a single page load.

Quick Wins

Add AsNoTracking() to read-only queries (instant memory savings)
Use projection instead of loading full entities
Check your logs for repeated similar queries (N+1 red flag)
Add indexes for your most common WHERE clauses

Debug Like a Pro

Enable query logging in development:

{
  "Logging": {
    "LogLevel": {
      "Microsoft.EntityFrameworkCore.Database.Command": "Information"
    }
  }
}

Use ToQueryString() to see what SQL EF Core generates before executing queries.

Bottom Line

Good EF Core performance isn't about tricks - it's about respecting what database operations actually cost. When you understand that every navigation property access might trigger a database call, you'll naturally write better code.

Most performance problems aren't in your business logic or UI. They're in those 5 lines of innocent-looking EF Core queries that seemed fine with test data.

Want the complete guide? I've written a detailed breakdown with full code examples, SQL output, and performance metrics at my post..

What EF Core performance issues have you run into? Drop a comment below.

Stop Making Everything a Plugin: The Real Open/Closed Principle

Abhinaw — Fri, 25 Jul 2025 07:01:36 +0000

The Open/Closed Principle (OCP) gets misunderstood a lot. It's not about turning every feature into a plugin system. It's about writing code that doesn't break when you add new stuff.

The Problem We're Solving

Here's what OCP violation looks like in real code:

public class PaymentProcessor
{
    public async Task<PaymentResult> ProcessPaymentAsync(PaymentRequest request)
    {
        switch (request.PaymentMethod)
        {
            case PaymentMethod.CreditCard:
                return await ProcessCreditCardAsync(request);
            case PaymentMethod.PayPal:
                return await ProcessPayPalAsync(request);
            // Every new payment method = modify this class
            default:
                throw new NotSupportedException();
        }
    }
}

Adding UPI Pay? You're modifying existing code. That's risky.

The Fix: Polymorphism Over Switch Statements

public interface IPaymentHandler
{
    PaymentMethod PaymentMethod { get; }
    Task<PaymentResult> ProcessAsync(PaymentRequest request);
}

public class PaymentProcessor(IEnumerable<IPaymentHandler> handlers)
{
    private readonly Dictionary<PaymentMethod, IPaymentHandler> _handlers = 
        handlers.ToDictionary(h => h.PaymentMethod);

    public async Task<PaymentResult> ProcessPaymentAsync(PaymentRequest request)
    {
        if (!_handlers.TryGetValue(request.PaymentMethod, out var handler))
            throw new NotSupportedException();

        return await handler.ProcessAsync(request);
    }
}

Now adding UPI Pay is just:

public class UpiPayHandler : IPaymentHandler
{
    public PaymentMethod PaymentMethod => PaymentMethod.UpiPay;

    public async Task<PaymentResult> ProcessAsync(PaymentRequest request)
    {
        // UPI Pay logic here
        return new PaymentResult { Success = true };
    }
}

Zero changes to existing code. That's OCP in action.

When to Actually Use This

Don't go crazy with abstractions. Use OCP when you have:

Business rules that change often (payment methods, tax calculations)
Multiple ways to do the same thing (different notification channels)
Algorithms you swap out based on conditions

Skip it for:

Simple data transformations
Configuration that rarely changes
One-off features

The Real Benefits

With proper OCP:

No regression risks - existing code stays untouched
Parallel development - teams can work on new handlers independently
Easy testing - each handler tests in isolation
Clean code - no more growing switch statements

Modern C# Makes This Easier

Using C# 12 primary constructors and dependency injection, this pattern is cleaner than ever. Register all your handlers automatically:

// In Program.cs
builder.Services.Scan(scan => scan
    .FromAssemblyOf<IPaymentHandler>()
    .AddClasses(classes => classes.AssignableTo<IPaymentHandler>())
    .AsImplementedInterfaces()
    .WithScopedLifetime());

The Bottom Line

OCP isn't about making everything pluggable. It's about identifying the parts of your code that actually change and making those parts extensible.

Look for growing switch statements and repeated "modify existing code to add feature X" patterns. Those are your OCP opportunities.

The goal is simple: add new features by writing new code, not by changing old code.

This post is part of my SOLID Principles Series.

Single Responsibility Principle - What's a "Single Reason to Change" and Why It Matters?

Abhinaw — Thu, 24 Jul 2025 12:26:37 +0000

The Single Responsibility Principle gets misunderstood more than any other SOLID principle. It's not about doing one thing, it's about having one reason to change. When your class changes for multiple business reasons, you've violated SRP and created a maintenance nightmare.

The Problem: Multiple Responsibilities in One Class

Here's a typical violation, a UserService that handles both validation and persistence:

public class UserService
{
    private readonly string _connectionString;

    public UserService(string connectionString)
    {
        _connectionString = connectionString;
    }

    public async Task<bool> CreateUserAsync(User user)
    {
        // Validation logic
        if (string.IsNullOrEmpty(user.Email) || !user.Email.Contains("@"))
            return false;

        if (user.Age < 18)
            return false;

        // Persistence logic
        using var connection = new SqlConnection(_connectionString);
        await connection.OpenAsync();

        var command = new SqlCommand(
            "INSERT INTO Users (Email, Age) VALUES (@email, @age)", 
            connection);

        command.Parameters.AddWithValue("@email", user.Email);
        command.Parameters.AddWithValue("@age", user.Age);

        await command.ExecuteNonQueryAsync();
        return true;
    }
}

This class has two reasons to change:

Business rule changes (validation requirements)
Data access changes (database schema, connection logic)

The Solution: Separate Responsibilities

public class UserValidator
{
    public ValidationResult Validate(User user)
    {
        var errors = new List<string>();

        if (string.IsNullOrEmpty(user.Email) || !user.Email.Contains("@"))
            errors.Add("Invalid email format");

        if (user.Age < 18)
            errors.Add("User must be at least 18 years old");

        return new ValidationResult(errors);
    }
}

public class UserRepository
{
    private readonly string _connectionString;

    public UserRepository(string connectionString)
    {
        _connectionString = connectionString;
    }

    public async Task SaveAsync(User user)
    {
        using var connection = new SqlConnection(_connectionString);
        await connection.OpenAsync();

        var command = new SqlCommand(
            "INSERT INTO Users (Email, Age) VALUES (@email, @age)", 
            connection);

        command.Parameters.AddWithValue("@email", user.Email);
        command.Parameters.AddWithValue("@age", user.Age);

        await command.ExecuteNonQueryAsync();
    }
}

public class UserService
{
    private readonly UserValidator _validator;
    private readonly UserRepository _repository;

    public UserService(UserValidator validator, UserRepository repository)
    {
        _validator = validator;
        _repository = repository;
    }

    public async Task<bool> CreateUserAsync(User user)
    {
        var validationResult = _validator.Validate(user);
        if (!validationResult.IsValid)
            return false;

        await _repository.SaveAsync(user);
        return true;
    }
}

What Qualifies as a "Reason to Change"?

A reason to change comes from different actors in your system:

Business stakeholders changing validation rules
DBAs changing database schemas
Security teams changing authentication requirements
Performance teams changing caching strategies

When the same class needs to change for requests from different actors, you've violated SRP.

Modern C# Features That Help With SRP

In C# 12 and .NET 8, we have several features that make adhering to SRP even easier:

Primary Constructors for Clean Dependency Injection

// C# 12 primary constructor syntax for clean DI
public class UserService(UserValidator validator, UserRepository repository)
{
    public async Task<bool> CreateUserAsync(User user)
    {
        var validationResult = validator.Validate(user);
        if (!validationResult.IsValid)
            return false;

        await repository.SaveAsync(user);
        return true;
    }
}

Record Types for Pure Data Classes

// Use records for DTOs to separate data from behavior
public record UserDto(string Email, int Age, string Name);

// Validator focused only on validation with no data access concerns
public class UserValidator
{
    public ValidationResult Validate(UserDto user) => new(
        IsValidEmail(user.Email) && user.Age >= 18
            ? Array.Empty<string>() 
            : new[] { "Invalid user data" }
    );

    private bool IsValidEmail(string email) => 
        !string.IsNullOrEmpty(email) && email.Contains('@');
}

Real-World Example: E-Commerce Order Processing

In a real e-commerce system, SRP violations often appear in order processing. Let's examine a better approach:

// Before: One massive service handling everything
public class OrderProcessor
{
    public async Task ProcessOrder(Order order)
    {
        // Inventory check
        // Payment processing
        // Shipping calculation
        // Notification sending
        // Analytics updating
        // All in one giant method!
    }
}

// After: Each responsibility gets its own service
public interface IInventoryService
{
    Task<bool> CheckInventoryAsync(Order order);
}

public interface IPaymentService
{
    Task<PaymentResult> ProcessPaymentAsync(Order order);
}

public interface IShippingService
{
    Task<ShippingDetails> CalculateShippingAsync(Order order);
}

public interface INotificationService
{
    Task SendOrderConfirmationAsync(Order order, ShippingDetails shipping);
}

// Coordinating service with a focused responsibility
public class OrderCoordinator(
    IInventoryService inventory,
    IPaymentService payment,
    IShippingService shipping,
    INotificationService notification,
    ILogger<OrderCoordinator> logger)
{
    public async Task<OrderResult> ProcessOrderAsync(Order order)
    {
        // Single responsibility: orchestrating the order flow
        try
        {
            if (!await inventory.CheckInventoryAsync(order))
                return new OrderResult(false, "Insufficient inventory");

            var paymentResult = await payment.ProcessPaymentAsync(order);
            if (!paymentResult.Success)
                return new OrderResult(false, paymentResult.Message);

            var shippingDetails = await shipping.CalculateShippingAsync(order);
            await notification.SendOrderConfirmationAsync(order, shippingDetails);

            return new OrderResult(true, "Order processed successfully");
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "Failed to process order {OrderId}", order.Id);
            return new OrderResult(false, "An error occurred");
        }
    }
}

public record OrderResult(bool Success, string Message);

Common SRP Pitfalls

"Helper" classes that become dumping grounds for unrelated functions

   // Bad: Utility class with unrelated responsibilities
   public static class StringHelper
   {
       public static string FormatForDisplay(string input) { /* ... */ }
       public static bool ValidateEmail(string email) { /* ... */ }
       public static string EncryptText(string text) { /* ... */ }  // Security concern
       public static string GenerateReportHeader() { /* ... */ }    // Report concern
   }

   // Better: Focused classes with clear responsibilities
   public static class StringFormatter { /* Display formatting only */ }
   public static class InputValidator { /* Validation only */ }
   public static class SecurityUtils { /* Encryption only */ }
   public static class ReportHelper { /* Report generation only */ }

Overly broad interfaces (IOrderService with 20+ methods)

   // Bad: Interface trying to do everything
   public interface IOrderService
   {
       Task<Order> GetOrderAsync(int id);
       Task<IEnumerable<Order>> GetAllOrdersAsync();
       Task<OrderValidationResult> ValidateOrderAsync(Order order);
       Task<int> SaveOrderAsync(Order order);
       Task<bool> ProcessPaymentAsync(Order order);
       Task<ShippingLabel> GenerateShippingLabelAsync(Order order);
       Task SendOrderConfirmationAsync(Order order);
       // ... 15 more methods
   }

   // Better: Focused interfaces by responsibility
   public interface IOrderRepository { /* Data access only */ }
   public interface IOrderValidator { /* Validation only */ }
   public interface IPaymentProcessor { /* Payment only */ }
   public interface IShippingService { /* Shipping only */ }

"Manager" classes that do too many things

   // Bad: UserManager with multiple responsibilities
   public class UserManager
   {
       public void RegisterUser(User user) { /* Auth, validation, DB, email */ }
       public void ResetPassword(string email) { /* Auth, DB, email */ }
       public UserStats GenerateUserStatistics() { /* Reporting logic */ }
       public void SyncWithExternalSystem() { /* Integration logic */ }
   }

   // Better: Split responsibilities
   public class UserRegistrationService { /* Registration only */ }
   public class PasswordService { /* Password management only */ }
   public class UserAnalyticsService { /* Statistics only */ }
   public class UserSyncService { /* External sync only */ }

"God" objects that grow indefinitely

   // Bad: Ever-growing Application class
   public class Application
   {
       private readonly DbContext _dbContext;
       private readonly HttpClient _httpClient;
       private readonly ILogger _logger;
       private readonly EmailSender _emailSender;
       // ... 10 more dependencies

       // Methods touching every aspect of the system
       public void Initialize() { /* ... */ }
       public void ProcessData() { /* ... */ }
       public void GenerateReports() { /* ... */ }
       // ... dozens more methods
   }

   // Better: Modular components with composition
   public class ApplicationBootstrapper { /* App initialization only */ }
   public class DataProcessor { /* Data processing only */ }
   public class ReportGenerator { /* Report generation only */ }

Tips for Maintaining SRP

Name classes after their responsibility - If you can't name it concisely, it might be doing too much
Keep classes under 200 lines - A rough guideline that encourages splitting up responsibilities
Ask "who might request changes" - If multiple teams would request changes, split the class
Use dependency injection - Makes it easier to compose single-responsibility components
Watch for "and" in class descriptions - "This class validates user input and saves to database" is a red flag

The Payoff

Now validation changes don't affect persistence code. Database migrations don't touch business rules. Each class has a single, focused responsibility and can evolve independently. This leads to:

Better testability - Test validation logic without a database
Easier maintenance - Changes are localized to relevant components
Improved team collaboration - Different teams can work on different responsibilities
More reusability - Single-purpose components are easier to reuse

This post is part of my SOLID Principles Series.

Interfaces, Abstract Classes, and DIMs in C#: A Real-World Developer’s Perspective

Abhinaw — Thu, 24 Jul 2025 10:48:30 +0000

As a C# developer, one of the most debated design decisions I've made (and seen others struggle with) is this:

"Should I use an interface, an abstract class, or a mix of both?"

It's not just about syntax or style, it's about shaping the future of your application. If you're building an extensible API, working on a SaaS platform, or simply trying to write better C# code, this question can dictate how testable, maintainable, and resilient your solution becomes.

In this post, I'll walk you through my personal learnings (and scars) from dealing with these choices, with links to in-depth posts for those who want to go deeper.

Interfaces: The Contract That Keeps Things Decoupled

Think of interfaces as promises, they define what a class can do without caring how it does it.

For example, an INotificationService contract can be implemented via Email, SMS, Push, or even Slack, and your OrderService doesn't need to know or care about the concrete type.

public interface INotificationService
{
    Task SendAsync(string recipient, string subject, string message);
}

This is the backbone of loose coupling and dependency injection, which makes your code testable and adaptable. Add a mock during testing, or swap implementations in production, no need to rewrite business logic.

Dive deeper into interfaces: Interface Contracts in C#: Decouple Code, Improve Testing, Embrace DI

Abstract Classes: Share Logic When There's a Real `Is-A` Relationship

Interfaces are great for "can-do" behaviors, but sometimes you want to enforce structure and also provide shared logic.

That's where abstract classes shine.

Imagine you're building a Document processing system where every type of document (PDF, Word, Excel) needs to be saved, validated, and tagged, but with different logic. Rather than duplicate common logic, you define an abstract base:

public abstract class Document
{
    public string Title { get; set; }

    public void UpdateMetadata(string title) => Title = title;

    public abstract void Save(string filePath);
}

Derived types implement the abstract methods, but reuse the shared methods.

You'll want to read: C# Abstract Classes: Real Examples, Patterns, and Best Practices

Interfaces with Default Implementations (DIMs): Friend or Foe?

Since C# 8.0, interfaces can have default implementations. Sounds great, right? You get some logic without breaking existing classes.

But default interface methods are not a replacement for abstract classes.

Here's why:

You can't have state or fields in interfaces.
All methods are public.
No constructors = no dependency injection.

Use DIMs for API evolution, like adding optional behavior without breaking older code.

public interface ILogger
{
    void Log(string message);

    void LogWithTimestamp(string message) =>
        Log($"[{DateTime.UtcNow}] {message}");
}

You get flexibility without forcing all implementers to change.

Explore this more: C# Default Interface Methods: Future-Proof and Backward-Compatible APIs

When to Use What?

Here's how I decide:

Use Case	Prefer Interface	Prefer Abstract Class
Multiple implementations needed (e.g., Email, SMS)	YES	NO
Shared logic or base workflow (e.g., database provider)	NO	YES
Requires constructor injection or state	NO	YES
Want to evolve API without breaking changes	YES (with DIMs)	YES (with virtual methods)
Testability / mocking	YES	HARD (test via derived concrete class)

Need more clarity? I created a breakdown of 10 real-world questions you should ask:
C# Abstract Class vs Interface: 10 Real-World Questions You Should Ask

Common Mistakes

Overusing interfaces: Don't abstract for the sake of it. If there's only one implementation, an interface may add unnecessary indirection.
Abusing DIMs: Keep default methods simple, don't bake in business logic that can't be tested or customized.
Using abstract classes in plugin systems: You limit flexibility. Prefer interfaces for plugin-style extensibility.

Final Thoughts

Use interfaces when you want flexibility and testability. Use abstract classes when you want shared behavior and structured inheritance. And use default interface methods when evolving APIs without breaking clients.

Each tool has its place. Mastering when to use what is the difference between duct-taped code and clean, scalable systems.

Want to learn more? Here are the full deep-dive posts this summary links to:

Let me know in the comments: What do you reach for first, interfaces or abstract classes?

DEV Community: Abhinaw

5 ASP.NET Core DI Scope Mistakes That Will Crash Your App

1. Registering DbContext as Singleton

2. Injecting Scoped Services into Singletons

3. Forgetting Scopes in Background Services

4. Misunderstanding Middleware Scopes

5. Overusing Transient for Heavy Objects

Quick Checklist

Read more

Applying OOP in ASP.NET Core

Encapsulation: Moving Beyond Property Getters and Setters

Abstraction: Interfaces That Actually Matter

Inheritance: When It Becomes a Problem

Polymorphism: Strategy Pattern in Action

What to Read Next

Conclusion

SOLID Principles Simplified: Cheatsheet + Interview Guide

S: Single Responsibility Principle (SRP)

O: Open/Closed Principle (OCP)

L: Liskov Substitution Principle (LSP)

I: Interface Segregation Principle (ISP)

D: Dependency Inversion Principle (DIP)

Further Reading

3 Signs Your Code Needs Middleware - ASP.NET Core

Sign #1: Repeating Code Across Controllers?

Sign #2: You're Modifying Requests or Responses Frequently

Sign #3: Your Services Depend on HttpContext

Performance Impact

Further Reading

Refactoring Messy Code: High Cohesion and Low Coupling

Spotting Low Cohesion

My Refactoring Approach

Reducing Coupling with Dependency Injection

Angular Example

Quick Quality Check

The Payoff

Related Posts

Stop Adding Async to Everything - It's Making Your C# Code Slower

The Big Misconception: Scalability != Speed

The Numbers Don't Lie

When Async Actually Helps

My Simple Rule: L.A.T.E.

The Real Problem: Async Contamination

Key Takeaway

HTTP Logging Middleware Tips That Actually Work in ASP.NET Core

The Big 3 Issues (And How to Fix Them)

Quick Wins You Can Implement Today

Built-in vs Custom: When to Choose What

Performance Tips That Matter

Clean Extension Method Pattern

Production Gotchas to Avoid

Where to Send Your Logs

Stop Your SQL JOINs from Crawling: A Quick Index Fix

The Problem Query

The Index Strategy That Actually Works

Results That Matter

Common Mistakes That Kill Performance

Pro Tips for Production

Quick Wins You Can Implement Today

11 EF Core Performance Mistakes That Will Kill Your App

1. The N+1 Query Problem

2. Premature ToList()

3. Client-Side Evaluation

4. Over-Fetching Data

5. Missing Indexes

6. Unnecessary Change Tracking

7. Lazy Loading Surprises

8. Poor DbContext Lifetime

9. Non-Compiled Repeated Queries

10. Individual Operations

11. No Performance Monitoring

The Real Cost

Quick Wins

Debug Like a Pro

Bottom Line

Stop Making Everything a Plugin: The Real Open/Closed Principle

The Problem We're Solving

The Fix: Polymorphism Over Switch Statements

When to Actually Use This

The Real Benefits

1. Registering `DbContext` as Singleton

Abstract Classes: Share Logic When There's a Real `Is-A` Relationship