Question

我正在开发和应用程序，我使用NInject框架来解决依赖项问题但是构造函数太大了。一些构造函数有5,8,10个参数。为了解决这个问题，我有一个想法..

而是像这样的代码类。

public class UserBLL
{
    private IA a;
    private IB b;
    ...
     UserBLL(IA a, IB b, IC c ...)
    {
        this.a = a;
        this.b = b
        ...
    }   

}

我认为代码是我的类。

    public class UserBLL
    {
        private IA a;
        private IB b;
        ...
         UserBLL(IKernel kernel)
        {
            this.a = kernel.Get<IA>();
            this.b = kernel.Get<IB>()
            ...
        }   

    }

我想知道这是不是一个好主意，以及它将来会遇到什么问题。

Answer 1

在第二个示例中，您根本没有简化构造函数。您添加了额外依赖项。这不是一个好主意。您希望组件取决于它所依赖的接口，而不是IKernel。

如果您的班级有8-10个依赖项，那可能是sign that the class is trying to do too much。

Answer 2

一个好的做法是注入IKernel insted业务接口依赖项

不，我认为这不是一个好习惯，您尝试将IKernel用作晚餐工厂，但请记住，您还要在代码中的任何位置创建对IKernel的依赖关系，它不是业务类，它是基础结构类。

在您的情况下，您可能违反单一责任原则，尝试将您的班级划分为较小的班级将是这种情况下的最佳诉讼。

Answer 3

我认为你在这里有一个好主意，但我不会像这样实施。内核对象的目标是使情况更清晰而不是迟钝。例如，我会这样做：

interface IKernel 
{
    public IA GetIA();
    public IB GetIB();      
}

注1：我会更进一步，实际解释他们在界面中的内容：

interface IKernel
{ 
   public IA GetUserUIPreferences();
   public IB GetPrintingParameters();
}

注2：我希望IKernel的任何实现都包含注入的功能 - 否则有什么意义？

Answer 4

不能注入IKernel实例。

注入能够任意解析其他组件的组件称为服务定位器，并被视为反模式。

关于服务定位器最糟糕的事情是它不再清楚某个类依赖于什么。这会产生一个可能不会立即显现的维护问题，但会在以后咬你。

这是一篇很好的文章，说明为什么使用服务定位器不是一个好主意：http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

关于构造函数中包含太多参数的问题：考虑更改设计。在大多数情况下，这是应用单一责任原则的问题，正如Iain Galloway在his answer中所建议的那样。基本上，您可以尝试在独立的类中拆分独立的逻辑片段，这些类将成为当前类的依赖关系，但同时会“窃取”某些现有的依赖关系。

因此，例如，如果类A有10个依赖项，您可以将逻辑拆分为三个类：B，C和D。这些中的每一个都可能具有以前由A直接使用的3-4个依赖项。

如果您认为3-4个依赖项也太多，您可以在那些较小的类中重复此过程。

是一个很好的做法Inject IKernel insted业务接口依赖项

4 个答案: