c# - 公共(public)服务登记处

Question

很长一段时间以来，我们一直很幸运能够使用公共(public)服务定位器 (CSL) 来解析来自未知来源的服务。但是，从来没有任何与容器无关的解决方案来首先注册这些服务。我们一直面临着必须将我们的组合代码耦合到特定的 IoC 容器的问题，而且，我们致力于在整个应用程序中使用该容器。

我觉得我可能试图在这里实现不可能的目标，但是有人对如何实现公共(public)服务注册中心 (CSR) 有任何想法吗？

我最初的想法是使用 MEF 来解析各种 IContainerIntegrator(每种容器技术一个类)，然后使用 MEF 来解析各种 IXXXContainerBinding(一个每种技术的接口(interface))。然后用户可以围绕容器绑定(bind)开发应用程序，只需将他们的绑定(bind)放入 BIN 目录即可实现插件架构。如果他们想使用新的容器技术，那么他们只需开发一个新的 IContainerIntegrator 类和随附的 IXXXContainerBinding，然后他们将使用它们来编写自己的绑定(bind)。在应用程序启动时，CSR 使用 ServiceLocatorAggregator 类将所有容器实例聚合到一个 CSL 中。

我已经开始工作了，但是我面临着以下问题:

• 任何调用当前(不完整)容器的绑定(bind)都是不稳定的，因为先前的注册可能被后续绑定(bind)覆盖。这包括需要解析对象以做出注册决定的绑定(bind)(即“如果存在则绑定(bind)”)。
• 可能存在公开同一组服务的两个绑定(bind)。但是，我们想要“交错”这些注册。例如。 '我希望服务 A 和 C 来自绑定(bind) X，服务 B 和 D 来自绑定(bind) Y'。
• 在自动连接所请求服务的依赖项时，容器会自行解析服务。例如。 “container.Bind .To ()”将自动注入(inject)从“container”解析的服务实现，而不是从聚合服务定位器。

如果我完全错过了这里的要点，请对我大喊大叫，但这不是最的依赖管理解耦解决方案吗？这不是很好吗？我即将开始一个具有插件架构的大型企业项目。我不想提交给特定的 IoC 容器。

(p.s. 这个问题是关于支持发现的与容器无关的组合。请不要就 SL 与 DI 进行辩论。SL 用于组合，这就是我在这里如此多地引用它的原因)。

Answer 1

您可以实现的最解耦(也是最好)的解决方案是认识到松散耦合最好通过原则和模式而不是特定技术来实现。

在整个应用程序中使用构造函数注入(inject)。这确保您的应用程序层根本不需要引用任何容器。那么compose the entire application graph in the root of the application .

您不需要为此使用 DI 容器，但如果您选择使用 DI 容器，则必须将它隔离到 Composition Root 。这意味着如果您以后决定迁移到不同的容器，您只需要更改 Composition Root。但是，Poor Man's DI 也是一种选择。