在库中允许使用IoC容器的策略是什么？

Question

问题其余部分的较短版本:我遇到了一个问题，而IoC容器是一个工具。这个问题听起来像是IoC可能能够解决的问题，但我还没有阅读足够的工具说明来确定地知道。我很好奇我是否选择了错误的工具，或者我可以跳到说明书的哪一章寻求帮助。

我在Windows窗体控件库上工作。在过去的一年里，我跌跌撞撞地进入了单元测试，并且对改进我们自动化测试的质量充满了热情。测试控件是困难的，而且在线上也没有多少关于它的信息。其中一件令人讨厌的事情是将交互逻辑与调用它的UI胶水分离开来，这导致每个控件具有比我通常认为对类健康的几个更多的依赖。在测试这些元素与控件的集成时，创建这些元素的假象相当繁琐，我正在研究IoC的解决方案。

有一个障碍我不知道怎么克服。要设置容器，需要在应用程序的其余部分之前运行一些引导程序代码。在一个应用程序中，有一个非常清晰的位置。在图书馆里就不太清楚了。

想到的第一个解决方案是创建一个类，该类提供容器的静态实例，并在其类型初始化器中设置容器。这对于运行时是有效的，但在测试环境中，我不确定它的工作效果如何。允许并行运行测试，许多测试将需要不同的依赖项，因此静态共享状态将是一场噩梦。这让我相信容器的创建应该是一个实例方法，但是我遇到了一个鸡和蛋问题，因为控件必须先构造它的容器，然后才能创建自己。控件的类型初始化器在脑海中浮现，但我的测试将无法修改此行为。这促使我考虑将容器本身作为控件的依赖项，其中用户可见构造函数提供运行时默认实现，但这将由我的测试来设置自己的容器。我还没有考虑过这一点，但看起来这与我现在所做的努力是一样的:每个测试必须初始化3-5依赖项的测试。

通常情况下，我会自己做很多事情，看看有什么疼的。目前我在一些苛刻的截止日期内，所以我在编写代码时没有太多的时间进行实验；我只有短暂的时间来思考这个问题，也没有把很多东西写在纸上。我相信其他人也有类似的问题，所以如果我不用重新发明轮子，那就太好了。

还有其他人攻击过这个问题吗？是否有一些解决这些需要的战略的例子？我只是一个新手，因为我缺乏经验而使事情变得过于复杂吗？如果是后者，我希望你能分享任何资源来解决我的无知。

更新：

我想回应马克西曼的答案，但它将需要更多的字符超过评论字段允许。

我已经在玩演示模型模式了。本例中的视图是公共控件类，每个类都有一个或多个控制器类。当某个UI事件在控件上触发时，它执行的唯一逻辑是决定需要调用哪些控制器方法。

这个设计的一个简短的表达方式就是我的控制器类与它们的视图紧密耦合。基于DI容器与松散耦合的代码一起工作的说法，我正在阅读“工作的错误工具”。我可能能够设计一个更松耦合的体系结构，此时DI容器可能更容易使用。但这将需要一些巨大的努力，这将是对已交付的代码的一次彻底改革；我将不得不在熟悉旧代码之前尝试使用新的东西。这是另一天的问题。

为什么我甚至想注入强耦合类型而不是使用本地默认值？有些接缝是高级用户的扩展点。我必须测试涉及不正确实现的各种场景，并验证我是否符合协议；模拟对象是非常合适的。

对于当前的设计，Chris关于“可怜人的DI”的建议或多或少是我一直遵循的，而对于我的强耦合类型，这只是很多繁琐的设置。我有这样的愿景，我可以把所有这些乏味的东西都推到DI容器安装方法中去，但是我越是试图证明这种方法的合理性，我就越相信我想用大锤挂照片。

我将等待大约24小时，看看讨论是否继续进行，然后才接受。

Answer 1

根据框架的复杂程度，您可以使用基于依赖项的手工编码构造函数，使用一个无参数的默认构造函数(该构造函数使用正常的具体实现)，但使用第二个构造函数，用于为单元测试目的注入依赖关系，例如。

private IMyDependency dependency;

public MyClass(IMyDependency dependency)
{
    this.dependency = dependency;
}

public MyClass() : this(new MyDefaultImplementation())
{

}

Answer 2

依赖注入(反转控制)是一组原则和模式，您可以使用这些原则和模式来编写松散耦合的代码。这是代码松散耦合的先决条件。DI容器不会使您的代码松散耦合的。

您需要找到一种将UI呈现与UI逻辑分离的方法。有很多表示模式描述了如何做到这一点：Model View Controller、Model View Presenter、Presentation Model等等。

一旦您有了良好的解耦，DI (和容器)就可以用来组成协作者。

Answer 3

由于库不应该对ioc框架本身有任何依赖，所以我们包含了带有库标准配置的spring.net ioc配置xml文件。这在理论上是模块化的，因为每个dll都有自己的子配置。然后，所有的下属都聚集在一起，成为主要招供的一部分。

但在现实中，这种方法容易出错，而且过于依赖:一个lib配置必须了解其他配置的属性，以避免重复。

我的结论是:要么使用@Chris“可怜人的依赖注入”，要么在主应用程序的大型、丑陋、紧密耦合的配置模块上处理所有依赖关系。