.NET 国际奥委会 : Preconfiguring library components for easier use

Question

前一段时间我有一个类似的问题，但对整个 IoC/DI 主题以及我想要实现的目标的了解要少得多，所以这里又来了....

我正在构建一个供公司内部通用的库。公共(public) API 中最常用的部分已经是 IoC 友好的，但是在较低级别的区域中，仍然有很多新的东西在进行，我想摆脱它(尽管此时更多的是出于正式原因而不是真正的原因必要性)。

这本身很容易做到，但当然每次使用库时，所有组件都必须重新连接。因为这看起来几乎总是一样的，所以我通常只是将这些默认注册包装在 Autofac 模块中并完成它。

(这是问题 1:这个模块会进入主库程序集还是应该是一个独立的包，即使 Autofac 可能是唯一与库一起使用的 IoC 容器？)

现在的问题是，我是目前公司里唯一一个真正看到IoC的用途或者完全知道IoC容器做什么的开发人员，更不用说它是如何使用的了，说出来是个坏主意对于其他人，他们可以使用 Autofac 包，也可以使用穷人的 DI 手动构建包含十几个以上对象的图形。 (我认识这些人——他们只会不管它，自己构建他们需要的东西，因为无论如何我都对我所有的小类(class)很着迷。)

我想解决这个问题的方法是添加类似服务定位器的东西，从中提取常用类型的预配置对象(看起来与 Autofac 模块连接的对象相同)，可能在内部连接轻量级 IoC 容器。

我知道 Service Locator 是一种反模式，它会产生哪些类型的问题，我永远不会将它用作(我的)对象组合方式，但作为 IoC/SOLID 受损的“捷径”，会可行吗？我还有什么其他选择？在这种情况下，将 Autofac 模块包含在库中并让“服务定位器”充当它的前端是否有意义？

Answer 1

对于框架，适用的规则与业务应用程序不同。在我看来，这在应用依赖注入(inject)时也适用。查看 Microsoft Patterns & Practices Enterprise Library 的设计时，您会看到这一点.它完全是围绕依赖注入(inject)模式设计的，但普通用户不会知道这一点。它使用工厂来让用户的生活更轻松。在您的情况下，强制其他开发人员使用依赖注入(inject)是不明智的，因为这可能只会惹恼他们，因为您所做的事情似乎只会让事情变得更难，而他们不会看到它的好处。这可能会给他们带来对整个 DI 事物的负面感觉，并且您将失去以后向他们介绍 DI 的可能性(因为他们已经下定决心不喜欢它)。

Would this module go in the main library assembly or should it be a standalone package

我通常不会将它集成到库本身中，因为从架构的角度来看，您根本不希望您的库依赖于任何 DI 容器。但是，当您查看 Enterprise Library 时，您会发现它对 Unity DI 框架有很强的依赖性。您可以更改 EntLib 以使用不同的容器，但 EntLib 仍引用 Unity。这允许框架设计者为用户提供方便的工厂方法，并且允许使用框架，而无需在您的应用程序中调用某种“Framework.Bootstrap”方法。

尽力使用 SOLID 设计您的框架牢记原则，因为您知道这是最好的做法。它还允许您在未来展示这种设计应用程序的方式(并且其他人可能会对依赖注入(inject)感兴趣)。但作为框架设计者，您必须考虑您的用户是谁，并想出适合他们的 API。例如，牢记 .NET 的框架设计指南可以提供很多帮助。

查看企业库时，您会看到根/主要类型有一个工厂。其他一切都在幕后为您解决。我认为这是要走的路。不要用 API 来打扰您的用户，因为他们需要自己连接所有东西，尤其是对于普通/简单的用例。