Понимание принципа инверсии зависимостей и создание жесткого контейнера IOC для собственной разработки для инъекций зависимостей без @Inject или @Autowired

Question

Я немного смущен различиями принципа инверсии SOLID и контейнеров IOC. Должен ли быть только один класс, ответственный за подключение всех зависимостей? Я не хочу использовать контейнер IOC для черных ящиков и сам прокладываю эти вещи. Я не хочу отвлекаться вначале, создавая собственный супер общий. Hardwiring в одном месте или классе будет просто отлично. Я также не хочу использовать любые @Inject или @Autowired и т. Д. Это просто скрывает сочные детали.

Я хочу понять, как я мог бы связывать зависимости в одном месте (класс или некоторый файл свойств) и иметь остальная часть системы не связана с конкретными реализациями. Я подхожу к этому, чтобы лучше понять, как работает инверсия зависимостей и как она связана с инъекцией зависимостей.

Итак, как я могу подключить интерфейс EmployeeDAO для сохранения и удаления сотрудников в базе данных или в файловой системе или в хранилище данных nosql? Я буду благодарен за любые примеры для этого использования.

Заранее благодарен.

Answer 1

Я бы порекомендовал вам не пытаться свернуть свой контейнер. Либо используйте контейнер с полки, либо вообще не используйте контейнер (похоже, что вы хотите его использовать).

public interface IEmployeeDAO 
{ 
    void SaveEmployee(Employee employee); 
} 

public class ClassThatNeedsToSaveEmployees 
{ 
    private readonly IEmployeeDAO _employeeDAO; 

    public ClassThatNeedsToSaveEmployees(IEmployeeDAO employeeDAO) 
    { 
    _employeeDAO = employeeDAO; 
    } 
} 

Теперь для создания экземпляра класса, вам нужно сделать что-то вроде этого:

var myClass = new ClassThatNeedsToSaveEmployees(new EmployeeDAO()); 

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

var myClass = new ClassThatNeedsToSaveEmployees(new EmployeeDAO(new DatabaseConnectionFactory(new ConfigurationFileReader()))); 

В простых приложениях, это не может быть проблемой, но по мере роста графика зависимости это становится более сложным для поддержания. Контейнер добавляет некоторую сложность в настройку вашего приложения (и немного кривой обучения), но он облегчает боль при добавлении зависимостей к вашим классам, заставляя их автоматически вводиться при условии, что они зарегистрированы правильно. Поэтому, если для реализации DatabaseConnectionFactory требуется дополнительная зависимость от IWidget, вы просто добавите параметр IWidget в конструктор, и он будет автоматически впрыснут.