这基本上是像 NInject 这样的 IOC 所做的事情吗？

发布于 2024-08-15 19:03:12 字数 648 浏览 4 评论 0原文

通常我会这样做：

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

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

（我问是否想知道它对我有何帮助的原因：帮助设计一个订单管理器类)

原文

Normally I would do this:

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

}

Where UserDao being the concrete implementation of IUserDao.

So now my code will be littered with:

DBFactory factory = new DBFactory();

IUserDao userDao = factory.GetUserDao();

User user = userDao.GetById(1);

Now if I wanted to swap implementaitons, I would have to go to my DBFactory and change my code to call a different implementation.

Now if I used NINject, I would bind the specific implementation on application startup, or via a config file. (or bind based on specific parameters etc. etc.).

Is that all there is too it? Or is there more?

(reason I am asking if I want to know how it will help me here: Help designing a order manager class)

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

翻身的咸鱼 2024-08-22 19:03:12

总之，是的。然后，您的代码的结构将发生变化，因此您的依赖项将通过构造函数（或设置器，我个人不喜欢）传递。您将不再为方法正文中的服务说“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);
     }     
}

In a word, yes. Your code would then change in structure, so your dependencies would be passed in via the constructor (or setters, which I am personally not a fan of). You would no longer say "new XXX()" for services in the body of your methods.

You also would not likely need the factory anymore at all, since the DI framework can act as a factory. You would likely just need a constructor dependency on IUserDAO.

So something like:

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

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

回复收藏 0 原文