【问题标题】:Introducing an IoC Container to Legacy Code将 IoC 容器引入遗留代码
【发布时间】:2009-01-15 17:36:46
【问题描述】:

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

但是,将调用此库的代码当前不使用任何类型的依赖注入,并且重构遗留代码以使用 DI 超出了我的项目的范围。那么,在这个遗留代码中开始使用容器从我的新库中获取实例的最佳方法是什么?

如果可能,我希望避免在我选择的任何 IoC 容器中使用硬引用来乱扔上述遗留代码。由于我对 DI 比较陌生,因此我们很可能会在某个时候改变我们想要使用哪个 Container 的想法。

如果我将容器包装在 CodePlex 上的 CommonServiceLocator 库中,这是一种合理的方法吗?

其他人做了什么?

【问题讨论】:

  • 谢谢。似乎与第一个答案非常相似。这正是我最终做的,顺便说一句。我创建了自己的 Container 类,它简单地包装了 Windsor,并让我的开发人员将其用作服务定位器。当然,在可行的情况下,我会尝试让他们仅在应用程序的引导部分使用容器,以避免在任何地方都依赖容器,但并不总是这样。毕竟这是遗留代码的情况。

标签: c# .net design-patterns dependency-injection


【解决方案1】:

您可以使用外观/代理模式从旧容器中隐藏 DI 容器。您实际上是将您的遗产硬连接到您实现的自定义类,该类将了解 DI 容器。现在,如果您修改您的 DI,您将更新您的外观而不是您的遗留代码。

我没有对 Common Service Locator 进行大量研究,但前提是它可能是一个很好的解决方案。您可能希望将外观与 CSL 联系起来,这将从您的遗留代码中完全隐藏 DI 概念。

【讨论】:

    【解决方案2】:

    据我了解,您希望从旧代码中调用启用 DI 的代码。

    最好的选择是保留新库DI Friendly, but container-agnostic

    这样做,您可以提供遗留代码可以使用的简单外观。旧版应用无需使用任何 DI 容器,也无需 Common Service Locator。

    【讨论】:

    • 这个简单外观的例子是什么? my question 中描述的静态函数目录是否算作简单外观?
    猜你喜欢
    • 2010-11-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-06-11
    • 2017-05-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多