向遗留代码引入IoC容器

10

我正在为我们公司编写一个新的.NET库,它将通过依赖注入使用IoC。自然地,如果我们使用IoC容器来解析实例,那么这个库会更容易使用。

但是,目前调用此库的代码并没有使用任何依赖注入,重构遗留代码以使用DI不在我的项目范围内。因此,在这个遗留代码中开始使用容器来获取来自我的新库的实例的最佳方法是什么?

如果可能的话,我想保持遗留代码不被硬编码引用我选择的任何IoC容器。由于我对DI相对较新,因此可能会在某个时候更改我们要使用的容器。

如果我将我的容器包装在CodePlex上的CommonServiceLocator库之类的东西中,这是否是一个合理的方法?

其他人都做了些什么?


http://davybrion.com/blog/2009/11/integrating-your-ioc-container-with-agatha/ - Ruben Bartelink
谢谢。第二个答案看起来与第一个非常相似。顺便说一下,这正是我最终所做的。我创建了自己的容器类,简单地包装了Windsor,并让我的开发人员将其用作服务定位器。当然,在可能的情况下,我尝试让他们仅在应用程序的引导部分中使用容器,以避免在任何地方都需要容器依赖,但并不总是奏效。毕竟,这是一个遗留代码的情况。 - Craig Vermeer
2个回答

4
你可以使用外观/代理模式来隐藏DI容器,使其不出现在你的旧容器中。实际上,你将旧容器硬编码到一个自定义类中,该类将了解DI容器。现在,如果你修改了DI,只需更新facade而不是旧代码。
我对常见服务定位器并没有进行过多的研究,但它的前提可能是一个很好的解决方案。你可能想将facade与CSL联系起来,这将完全隐藏DI概念,使其不出现在旧代码中。

2

据我理解,您想从传统代码中调用启用DI的代码。

最好的选择是保持新库 DI友好但与容器无关

这样做,您可以提供一个简单的门面,传统代码可以使用。 传统应用程序不需要使用任何DI容器,也不需要使用公共服务定位器。


那么简单的外观模式有什么例子呢?在我的问题中描述的静态函数目录是否算作一个简单的外观模式? - Vin Shahrdar

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接