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，我会在应用程序启动时绑定特定的实现，或者通过配置文件绑定。（或基于特定参数等进行绑定等）。

这就是全部吗？或者还有更多？

（我问我是否想知道它对我有什么帮助：Help designing a order manager class）

Answer 1

总之，是的。然后你的代码会在结构上发生变化，所以你的依赖关系会通过构造函数（或者我不喜欢的setter）传递。你不会再对你方法体内的服务说“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自动创建并注入这些对象，保存一些代码行，但更重要的是确保每个类都与其依赖项松散耦合。

这基本上是像NInject那样的IOC吗？

2 个答案: