共同服务登记处

Question

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

我觉得我可能试图在这里实现不可能,但是有没有人对如何实现公共服务注册表(CSR)有任何想法？

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

我有这个工作,但面临以下问题:

• 任何调用当前(不完整)容器的绑定都是不稳定的,因为之前的注册可能会被后续绑定覆盖.这包括需要解析对象以进行注册决策的绑定(即"如果存在则绑定它").
• 可能存在两个绑定,它们暴露同一组服务.但是,我们希望"交织"这些注册.例如'我希望服务A和C来自绑定X,服务B和D来自绑定Y'.
• 当自动连接所请求服务的依赖关系时,容器会自行解析服务.例如'container.Bind <This> .To <That>()'将自动注入来自'container'解析的服务的实现 - 而不是来自聚合服务定位器.

如果我完全忽略了这一点,请大声喊叫,但这不是依赖管理最脱钩的解决方案吗？不是很好吗？我即将开始使用插件架构开展大型企业项目.我不想承诺特定的IoC容器.

(ps这个问题是关于容器不可知的组合,它支持发现.请不要进入关于SL与DI的争论.在组合中使用SL,这就是我在这里引用它的原因).

Answer 1

您可以实现的解耦(和最佳)解决方案是通过原理和模式而不是特定技术来实现松散耦合.

在整个应用程序中使用构造函数注入.确保您的应用程序层都不需要引用任何容器.然后在应用程序的根目录中编写整个应用程序图.

您不需要使用DI容器,但如果您选择使用DI容器,则必须将其与组合根隔离.这意味着如果您以后决定迁移到其他容器,则只需更改组合根.然而,穷人的DI也是一种选择.