.NET IoC：预配置库组件以便于使用

Question

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

我正在建立一个库，供我们公司内部使用。公共 API 中最常用的部分已经对 IoC 友好，但在较低级别的区域中，仍有相当多的新功能在进行，我想摆脱它们（尽管此时更多是出于正式原因而不是实际原因必要性）。

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

（这里的问题 1：这个模块是放在主库程序集中还是应该是一个独立的包，即使 Autofac 可能是唯一与库一起使用的 IoC 容器？）

现在的问题是，我目前是公司中唯一真正了解 IoC 用途或完全了解 IoC 容器做什么的开发人员，更不用说它是如何使用的了，告诉我是个坏主意其他所有人，他们可以使用 Autofac 包，也可以使用穷人的 DI 手动构建十几个对象的图形。 （我认识这些人——他们会不理会它，自己构建他们需要的东西，因为无论如何我都为我所有的小班而疯狂。）

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

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

Answer 1

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

这个模块会放在主库程序集中还是应该是一个独立的包

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

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

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