调整现有系统以使用依赖注入并非易事，但值得付出努力。这种方法的架构优势包括更快的开发，更容易的缺陷修复，显着增强的单元测试可能性和整体质量改进。

引入依赖注入所需的大部分工作都是在引入模式之前发生的。准备现有代码通常占用引入依赖注入（DI）所需时间的50％以上。以下是有关如何使此过程更顺利的一些提示。

实现数据访问层

无论应用程序的新旧程度如何，数据访问可能是应用程序的一个非常大的部分。在旧系统中，可以在整个代码中找到数据库查询 - 实质上是将代码与数据库结构紧密耦合。但由于数据库是系统中最不灵活的部分之一，因此这种耦合很快就会抵消转换为DI的优势。要解决此问题，请引入数据访问层（DAL）。

DAL有两个目标。首先，它从您的应用程序中抽象出数据库引擎，因此您可以随时更改数据库 - 例如，从Microsoft SQL到Oracle。这在实践中很少进行，并且不足以使重构现有应用程序以使用DAL。

第二个目标是从数据库实现中抽象出数据模型。这允许数据库或代码在必要时进行更改，同时仅影响主应用程序的一小部分--DAL。这个目标值得在现有系统中实现它所需的重构工作。

添加DAL的另一个好处是增强了单元测试能力。如果没有DAL，测试必须使用数据库中的实际数据。这意味着必须在测试数据库中创建支持不同方案的数据，并且该数据库必须保持在常量状态。这很难做到并且容易出错。有了DAL，就可以编写测试来创建测试不同场景所需的任何类型的数据库数据。它还允许您测试在数据库不可用或查询期间崩溃时会发生什么。在使用真实数据库时，这些边缘情况几乎不可能按需重现。

重构模块和接口

依赖注入背后的核心思想之一是单一责任原则。该原则规定每个对象应具有特定目的，并且需要利用该目的的应用程序的不同部分应使用适当的对象。这意味着这些对象可以在系统中的任何位置重复使用。在现有系统中，这通常是不真实的。因此，引入DI的第一步是重构应用程序以使用专用类或模块用于特定目的。

实现DI的机制需要使用与已发布的方法和要使用的不同模块的属性相匹配的接口。在将功能重构为模块时，应该重构应用程序以使用这些接口而不是具体类。

请注意，这种重构都不会影响应用程序的逻辑流程。这是一个移动代码的练习，而不是改变它的工作方式。为确保不引入缺陷，请遵循正常的质量保证（QA）流程。但是，如果正确完成，创建错误的可能性很小。

随时添加单元测试

将功能包含在单个对象内部使得自动化测试变得困难或不可能。重构模块和接口隔离特定对象，并允许更高级的单元测试。很有可能继续重构模块，以便稍后回来并添加测试，但这是一个错误。

在重构代码时，引入新缺陷始终是一个问题。尽快创建单元测试可以解决这一风险，但也很少考虑项目管理风险。立即添加单元测试可以检测遗留代码中已存在的缺陷，但未被发现。我认为，如果当前系统已运行一段时间，这些不应被视为缺陷，而是“未记录的功能”。然后，您必须决定是否需要解决这些问题或将其保留原样。

使用服务位置，而不是构造函数注入

实现依赖注入的方法不止一种。最常见的方法是使用构造函数注入，这需要在首次创建对象时提供所有软件依赖性。但是，构造函数注入假设整个系统正在使用模式，这意味着整个系统必须同时进行重构。这是困难，危险和耗时的。

构造函数注入的另一种方法是服务位置。这个模式可以缓慢实现，一次重构一个应用程序，这很方便。现有系统的缓慢适应优于大规模转换工作。因此，在将现有系统调整为DI时，服务位置是最佳使用模式。

有些人批评服务定位器模式，称它取代了依赖关系而不是消除紧密耦合。我从头开始构建应用程序时同意这一点，但在更新现有系统时，在转换期间使用服务定位器很有价值。当整个系统适应服务定位器时，转换为构造函数注入是一个微不足道的额外步骤。