Это в основном то, что делает IOC, такой как NInject?

Question

Обычно я бы сделал это:

public class DBFactory
{
        public UserDAO GetUserDao()
        {
               return new UserDao();     
        }

}

Где UserDao - конкретная реализация IUserDao.

Так что теперь мой код будет усеян:

DBFactory factory = new DBFactory();

IUserDao userDao = factory.GetUserDao();

User user = userDao.GetById(1);

Теперь, если бы я хотел поменять местами реализации, мне нужно было бы перейти к моей DBFactory и изменить мой код для вызова другой реализации.

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

И это все? Или есть еще?

(причина, по которой я спрашиваю, хочу ли я узнать, как это мне поможет, здесь: Помощь в разработке класса менеджера заказов )

Answer 1

Одним словом, да. Ваш код будет тогда меняться по структуре, поэтому ваши зависимости будут передаваться через конструктор (или сеттеры, которые я лично не фанат). Вы больше не сказали бы «new XXX ()» для служб в теле ваших методов.

Вам также вряд ли понадобится фабрика вообще, так как структура DI может действовать как фабрика. Скорее всего, вам просто понадобится зависимость конструктора от IUserDAO.

Так что-то вроде:

public class ClassThatNeedsUserDAO
{
     private readonly IUserDAO _userDAO;
     public ClassThatNeedsUserDAO(IUserDAO userDAO)
     {
         _userDAO = userDAO;
     }

     public User MyMethod(userId)
     {
         return _userDAO.GetById(int userId);
     }     
}

Answer 2

Это еще не все, один пример был бы, если бы конструктор UserDao требовал, чтобы некоторые другие объекты передавались в качестве аргументов (зависимостей).

Вы могли бы иметь возможность автоматически создавать и внедрять эти объекты в ninject, сохраняя некоторые строки кода, но, что более важно, гарантируя, что каждый класс слабо связан со своими зависимостями.