Как используешь букву D из SOLID в своих приложениях?

Принцип инверсии зависимостей (Dependency Inversion Principle) в моих приложениях

Принцип инверсии зависимостей (DIP) — это пятая буква в акрониме SOLID, который гласит:

1. Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций
2. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций

Конкретная реализация DIP в архитектуре

В своих приложениях я применяю DIP через несколько ключевых практик:

1. Внедрение зависимостей через интерфейсы

Вместо прямого создания зависимостей внутри классов, я определяю контракты через интерфейсы и внедряю реализации через конструкторы или свойства.

// Абстракция (интерфейс)
public interface IOrderRepository
{
    Task<Order> GetByIdAsync(int id);
    Task SaveAsync(Order order);
}

// Модуль высокого уровня (не зависит от конкретной реализации)
public class OrderService
{
    private readonly IOrderRepository _repository;
    
    // Зависимость инжектируется через конструктор
    public OrderService(IOrderRepository repository)
    {
        _repository = repository;
    }
    
    public async Task<Order> ProcessOrder(int orderId)
    {
        var order = await _repository.GetByIdAsync(orderId);
        // Бизнес-логика
        await _repository.SaveAsync(order);
        return order;
    }
}

// Модуль низкого уровня (зависит от абстракции)
public class SqlOrderRepository : IOrderRepository
{
    public async Task<Order> GetByIdAsync(int id)
    {
        // Реализация работы с SQL Server
    }
    
    public async Task SaveAsync(Order order)
    {
        // Реализация сохранения в SQL Server
    }
}

2. Использование IoC-контейнеров

Для управления зависимостями применяю контейнеры инверсии управления:

// Конфигурация в Startup.cs или Program.cs
services.AddScoped<IOrderRepository, SqlOrderRepository>();
services.AddScoped<IOrderRepository, MongoOrderRepository>(); // Альтернативная реализация

// Для тестирования можно легко подменить
services.AddScoped<IOrderRepository, MockOrderRepository>();

3. Слоистая архитектура с четким разделением

• Domain Layer (ядро) — содержит бизнес-правила и интерфейсы репозиториев
• Infrastructure Layer — реализует интерфейсы из Domain Layer (репозитории, внешние сервисы)
• Application Layer — координирует работу, зависит только от интерфейсов Domain Layer
• Presentation Layer — зависит от Application Layer

4. Паттерн Dependency Injection в ASP.NET Core

Встроенная поддержка DI в ASP.NET Core идеально соответствует DIP:

public class ProductsController : ControllerBase
{
    private readonly IProductService _productService;
    private readonly ILogger<ProductsController> _logger;
    
    // Фреймворк инжектирует зависимости автоматически
    public ProductsController(IProductService productService, ILogger<ProductsController> logger)
    {
        _productService = productService;
        _logger = logger;
    }
    
    [HttpGet("{id}")]
    public async Task<IActionResult> GetProduct(int id)
    {
        var product = await _productService.GetProductAsync(id);
        return Ok(product);
    }
}

Практические преимущества в реальных проектах

Гибкость и расширяемость:

• Легкая замена реализации (переход с SQL Server на PostgreSQL)
• Возможность добавления кеширования через декоратор
• Поддержка различных поставщиков данных (база данных, файловая система, облачное хранилище)

Тестируемость:

// Unit-тесты с моками зависимостей
[Test]
public async Task ProcessOrder_Should_CallRepository()
{
    // Arrange
    var mockRepository = new Mock<IOrderRepository>();
    mockRepository.Setup(r => r.GetByIdAsync(It.IsAny<int>()))
                 .ReturnsAsync(new Order());
    
    var service = new OrderService(mockRepository.Object);
    
    // Act
    await service.ProcessOrder(1);
    
    // Assert
    mockRepository.Verify(r => r.SaveAsync(It.IsAny<Order>()), Times.Once);
}

Управление жизненным циклом объектов:

• Singleton для общих сервисов (конфигурация, кеш)
• Scoped для контекстных зависимостей (DbContext в EF Core)
• Transient для легковесных сервисов

Реальный пример из production-проекта

В одном из проектов электронной коммерции мы использовали DIP для реализации механизма уведомлений:

public interface INotificationService
{
    Task SendAsync(Notification notification);
}

// Множественные реализации
public class EmailNotificationService : INotificationService { }
public class SmsNotificationService : INotificationService { }
public class PushNotificationService : INotificationService { }

// Композитная реализация для отправки через все каналы
public class CompositeNotificationService : INotificationService
{
    private readonly IEnumerable<INotificationService> _services;
    
    public CompositeNotificationService(IEnumerable<INotificationService> services)
    {
        _services = services;
    }
    
    public async Task SendAsync(Notification notification)
    {
        var tasks = _services.Select(s => s.SendAsync(notification));
        await Task.WhenAll(tasks);
    }
}

Ключевые выводы

DIP позволяет:

• Снизить связанность между компонентами системы
• Упростить тестирование через изоляцию зависимостей
• Повысить гибкость архитектуры для будущих изменений
• Улучшить читаемость кода через явное объявление зависимостей
• Поддерживать принцип открытости/закрытости (OCP) — новые реализации добавляются без изменения существующего кода

На практике DIP становится фундаментом для создания поддерживаемых, тестируемых и масштабируемых приложений, особенно в сочетании с остальными принципами SOLID и современными фреймворками .NET, которые изначально спроектированы с поддержкой dependency injection.