对具有许多依赖项的类使用依赖注入框架

我一直在研究.NET的各种依赖注入框架,因为我觉得我正在开发的项目将从中受益匪浅.虽然我认为我已经很好地掌握了这些框架的功能,但我仍然不清楚如何最好地将它们引入大型系统.大多数演示(可以理解)往往是具有一个或两个依赖关系的非常简单的类.

我有三个问题......

首先,您如何处理那些常见但无趣的依赖关系,例如ILog,IApplicationSettings,IPermissions,IAudit.对于每个类来说,在构造函数中将这些作为参数似乎有点过分了.在需要时使用DI容器的静态实例来获取它们会更好吗？

MyClass(ILog log, IAudit audit, IPermissions permissions, IApplicationSettings settings)
// ... versus ...
ILog log = DIContainer.Get();

其次,如何处理可能使用的依赖项,但创建起来可能很昂贵.示例 - 类可能依赖于ICDBurner接口,但不希望创建具体实现,除非实际使用了CD刻录功能.您是否在构造函数中将接口传递给工厂(例如ICDBurnerFactory),或者您是否再次采用静态方式直接获取DI Container并在需要时询问它？

第三,假设您有一个大型Windows窗体应用程序,其中顶级GUI组件(例如MainForm)可能是数百个子面板或模态窗体的父级,每个子面板或模式窗体可能具有多个依赖关系.这是否意味着应该将MainForm设置为具有其子项的所有依赖项的超集作为依赖项？如果你这样做了,最终是否会创建一个巨大的自我膨胀怪物来构建你创建MainForm时可能需要的每一个类,在这个过程中浪费时间和记忆？

1> Nikola Malov..：

---

好吧,虽然您可以按照其他答案中的描述执行此操作,但我相信对于您的示例有更重要的事情需要回答,那就是您可能违反了SRP原则,并且具有许多依赖关系的类.

我在你的例子中会考虑的是在几个更连贯的类中分解类,并且关注的问题因此依赖的数量会下降.

尼古拉的SRP和DI法则

"任何有超过3个依赖关系的类都应该被质疑SRP违规"

(为了避免冗长的回答,我在IoC和SRP博客文章中详细介绍了我的答案)

---

很公平,但正如我在你的博客上评论的那样 - 我将IoC引入了一个拥有近100万行代码的项目.我无法在一夜之间修复所有违反SRP的行为.我们现在正在使用Unity,而且事情正朝着正确的方向缓慢前进.

2> Maurice..：

---

第一步:根据需要将简单依赖项添加到构造函数中.没有必要为每个构造函数添加每个类型,只需添加您需要的类型.需要另一个,只需展开构造函数.性能不应该是一件大事,因为大多数这些类型可能是单身人士,因此在第一次通话后已经创建.不要使用静态DI容器来创建其他对象.而是将DI容器添加到自身,以便它可以将自身解析为依赖关系.所以这样的事情(暂时假设Unity)

IUnityContainer container = new UnityContainer();
container.RegisterInstance(container);

这样您就可以在IUnityContainer上添加一个依赖项,并使用它来创建昂贵或很少需要的对象.主要优点是单元测试更容易,因为没有静态依赖.

第二:无需通过工厂课程.使用上述技术,您可以使用DI容器本身在需要时创建昂贵的对象.

三:将DI容器和轻型单件依赖项添加到主窗体,并根据需要通过DI容器创建其余部分.需要更多代码,但正如您所说,如果您在启动时创建所有内容,则主体的启动成本和内存消耗将会达到顶峰.

---

恕我直言,注入IContainer同样是一个糟糕的想法,如ServiceLocator的不透明使用,因为它(也)隐藏了依赖性,阻止了有效的重构和黑盒测试.

---

问题好，但答案的选择差。此答案中的所有三个（子答案）都是反模式，根本不应该使用。