.NET Design Pattern Review

.NET Design Pattern Review is an AI skill that analyzes .NET codebases to identify design pattern usage, detect anti-patterns, and recommend improvements aligned with modern .NET best practices. It provides actionable feedback on pattern implementation quality.

What Is This?

Overview

.NET Design Pattern Review examines C# and .NET code for both correct and incorrect applications of common design patterns. It detects patterns like Repository, Unit of Work, Factory, Strategy, Observer, and Dependency Injection, then evaluates whether they are implemented idiomatically for the .NET ecosystem. The skill identifies anti-patterns such as service locator misuse, god classes, and excessive abstraction layers, providing specific refactoring suggestions with code examples that demonstrate the recommended approach.

Who Should Use This

This skill is designed for .NET architects reviewing codebases for structural quality, senior developers mentoring teams on design pattern best practices, development leads conducting code audits before major releases, and teams refactoring legacy .NET Framework applications to modern .NET patterns.

Why Use It?

Problems It Solves

.NET projects accumulate architectural debt when design patterns are applied inconsistently or incorrectly. Developers may implement patterns they have read about without adapting them to .NET conventions, resulting in overly complex code that is harder to maintain than simpler alternatives. Anti-patterns like the anemic domain model or excessive interface extraction create bloat without delivering the flexibility they promise.

Core Highlights

The skill evaluates pattern implementations against current .NET idioms, not just textbook definitions. It considers the built-in dependency injection container, async/await patterns, record types, and minimal API conventions when making recommendations. Reviews highlight both over-engineering and under-engineering.

How to Use It?

Basic Usage

// Review finding: Service Locator anti-pattern detected
// Before: using service locator instead of constructor injection
public class OrderProcessor
{
    public void Process(Order order)
    {
        var validator = ServiceLocator.Get<IOrderValidator>();
        var repository = ServiceLocator.Get<IOrderRepository>();
        validator.Validate(order);
        repository.Save(order);
    }
}

// Recommended: constructor injection via DI container
public class OrderProcessor
{
    private readonly IOrderValidator _validator;
    private readonly IOrderRepository _repository;

    public OrderProcessor(IOrderValidator validator, IOrderRepository repository)
    {
        _validator = validator;
        _repository = repository;
    }

    public void Process(Order order)
    {
        _validator.Validate(order);
        _repository.Save(order);
    }
}

Real-World Examples

// Review finding: Generic repository adds unnecessary abstraction
// Before: wrapping EF Core in a generic repository
public interface IRepository<T> where T : class
{
    Task<T> GetByIdAsync(int id);
    Task<IEnumerable<T>> GetAllAsync();
    Task AddAsync(T entity);
}

// Recommended: use DbContext directly with specific query methods
public class OrderService
{
    private readonly AppDbContext _db;

    public OrderService(AppDbContext db) => _db = db;

    public async Task<Order> GetOrderWithItemsAsync(int orderId)
    {
        return await _db.Orders
            .Include(o => o.Items)
            .FirstOrDefaultAsync(o => o.Id == orderId);
    }
}
// EF Core already implements Repository and Unit of Work patterns.
// Wrapping it adds complexity without meaningful abstraction benefit.

Advanced Tips

Run the review at the solution level to detect inconsistent pattern usage across projects within the same solution. Provide context about your team size and project lifecycle stage, as pattern recommendations differ between small prototypes and large enterprise applications. Use the review iteratively after refactoring to verify that changes align with the recommended patterns.

When to Use It?

Use Cases

Use .NET Design Pattern Review when auditing code quality before major releases or architecture changes, when onboarding to a legacy codebase and needing to understand its structural patterns, when planning refactoring efforts and needing to prioritize which patterns to address first, or when establishing coding standards for a new .NET project.

Related Topics

SOLID principles in .NET, dependency injection with Microsoft.Extensions.DependencyInjection, Entity Framework Core patterns, clean architecture in ASP.NET Core, MediatR and CQRS patterns, and .NET code analysis tools like Roslyn analyzers all complement the design pattern review process.

Important Notes

Requirements

The skill works with C# code targeting .NET 6 and later, .NET Framework 4.6.2 and later, and .NET Standard libraries. Providing the full solution structure including project references helps identify cross-project pattern issues. NuGet package references provide context about which frameworks influence the recommended patterns.

Usage Recommendations

Do: provide context about your project goals and constraints when requesting a review. Address anti-pattern findings before optimizing correct but imperfect pattern implementations. Use the review findings as discussion points in team architecture reviews rather than applying all suggestions mechanically.

Don't: add patterns purely because the review identifies where they could be applied. Refactor working code without corresponding test coverage to catch regressions. Assume every generic repository should be removed without evaluating whether it provides genuine value in your specific context.

Limitations

The skill evaluates structural patterns in code but cannot assess runtime behavior or performance characteristics that depend on deployment context. Business logic correctness is outside the scope of pattern review. Very large solutions may need to be reviewed in segments for the most detailed feedback.