1

我正在开发和应用程序，我使用 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>()
            ...
        }   

    }

我想知道这是否是一个好主意，以及我将来是否会遇到任何问题。

4

4 回答 4

1

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

如果您的班级有 8-10 个依赖项，这可能表明班级正在尝试做太多的事情。

于 2013-02-04T16:50:35.680 回答
1

注入IKernel insted业务接口依赖是一个好习惯

不，我认为这不是一个好习惯，您正在尝试将其IKernel用作超级工厂，但请记住，您还会在代码中的任何地方创建依赖关系IKernel，这不是业务类，而是基础设施类。

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

于 2013-02-04T16:53:34.440 回答
0

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

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

注1：我会走得更远，并实际解释他们在界面中的内容：

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

注 2：我希望 IKernel 的任何实现都包含注入的功能——否则，拥有 DI 的意义何在

于 2013-02-04T16:52:28.463 回答
0

IKernel不，注入实例是不行的。

注入一个能够任意解析其他组件的组件称为服务定位器，被认为是一种反模式。

Service Locator 最糟糕的事情是它不再清楚某个类依赖于什么。这会产生一个维护问题，可能不会马上明显，但以后会咬你。

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

关于构造函数参数过多的问题：考虑改变设计。在大多数情况下，这是应用单一职责原则的问题，正如 Iain Galloway 在他的回答中所建议的那样。基本上，您可以尝试在单独的类中分解独立的逻辑部分，这些部分将成为当前类的依赖项，但同时会“窃取”一些现有的依赖项。

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

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

于 2013-02-04T17:08:04.370 回答