根据一位专家的说法，将现有应用与依赖注入适配的努力是值得的。遵循下列提示让该过程平滑运转。
让现有系统适配以使用依赖注入并非鸡毛蒜皮，而是一项值得的努力。该方法的架构性优势包括更快的开发、更容易的缺陷修复，单元测试可能性的显著增强，以及总体的质量改进。
这些工作大部分需要在模式被引入前先引入依赖注入。准备现有代码往往需要占用超过引入依赖注入（DI）所需时间的50%。以下是如何让这一过程走得更顺畅一些的提示。
实现数据访问层
你的应用无论有多新或者有多旧，数据访问也许是应用很大的一部分。在更老的系统中，数据库查询在代码中都随处可见基本上都是把代码跟数据库结构绑定在一起。但是因为数据库是系统最灵活的部分之一，这种耦合会迅速抵消掉向依赖注入的转换的好处。为了解决这个问题，可以引入数据访问层（DAL）。
DAL有两个目标。第一是将数据库引擎从应用中抽象出来，这样你就可以随时改变你的数据库比方说，从微软SQL变成Oracle。不过在实践上很少会这么做，也没有足够的理由未来使用DAL而进行重构现有应用的努力。
第二个目标是将数据模型从数据库实现中抽象出来。这使得数据库或代码开源根据需要改变，同时只会影响主应用的一小部分DAL。这一目标是值得的，为了在现有系统中实现它进行必要的重构。
增加DAL的一个额外的好处是增强了单元测试能力。没有DAL，测试就必须利用数据库的真实数据。这意味着支持不同场景的数据必须在测试数据库中创建，而这个数据库必须维持一种恒定的状态。这很难做且容易引起错误。而有了DAL，就可以创建必要的任何类型的数据库数据来测试不同场景，以这种方式来写测试。它还可以让你在没有数据库或数据库因查询崩溃期间测试发生了什么事情。如果是用真实数据库来做，要想根据需要复制这些边界情况几乎是不可能的。
模块与接口重构
依赖注入背后的一个核心思想是单一功能原则（single responsibility principle）。该原则指出，每一个对象应该有一个特定的目的，而应用需要利用这一目的的不同部分应当使用合适的对象。这意味着这些对象在系统的任何地方都可以重用。但在现有系统里面很多时候都不是这样的。因此，引入DI的第一步就是对应用进行重构，以便用针对特定目的使用专门的类或模块。
DI的实现机制需要使用匹配被用的不同模块的发布方法和属性的接口。当把功能性重构进模块时，应用也应该进行重构以便利用这些接口而不是具体的类。
要注意的是，这一重构应该影响应用的逻辑流。这是移动代码的实践，不是改变它的工作方式。为了确保不会引入缺陷，需要遵循质保（QA）流程。然而，做法得当的话，产生bug的机会是很小的。
随时增加单元测试
把功能封装到整个对象里面会导致自动测试困难或者不可能。将模块和接口与特定对象隔离，以这种方式重构可以执行更先进的单元测试。按照后面再增加测试的想法继续重构模块是诱惑力的，但这是错误的。
引入新的缺陷永远是重构代码的一大担忧。尽快建立单元测试可以处置这个风险，但是还存在着一个很少会被考虑到的项目管理风险。马上增加单元测试可以检测出遗留代码原有未被发现的缺陷。我要指出的是，如果当前系统已经运行了一段时间的话，那么这些就不应该被视为缺陷，而是“未记录的功能”。此时你必须决定这些问题是否需要处置，还是放任不管。
使用服务定位器而不是构造注入
实现依赖注入不止一种方法。最常见的办法是使用构造注入，这需要在对象首次被创建是提供所有的软件依赖。然而，构造注入要假设整个系统都使用这一模式，这意味着整个系统必须同时进行重构。这很困难、有风险，且耗时。
构造注入有一个替代方法，就是服务定位器。这种模式可以慢慢实现，即每次在方便的时候只对应用的一部分进行重构。对现有系统的慢慢适配要比大规模转换的努力更好。因此，在让现有系统适配DI时，服务定位是最佳使用模式。
有人批评服务定位器模式，说它取代了依赖而不是消除了紧耦合。如果是从头开始开发应用的话，我同意这种说法，但是如果是对现有系统进行升级，过渡期间使用服务定位器是有价值的。当整个系统已经适配了服务定位器之后，再把它转化为构造注入就是一个可有可无的步骤了。
应用开发
2014服务器端趋势：模块化和组件化的应用服务器
应用开发者促进个性化定制软件的开发
中间件可帮助企业实现应用现代化
如何在设计和性能之间建立平衡
应用开发工具帮助报社与时俱进
应用开发的美学之道
持续软件开发促进Edmunds.com创新
HealthCare.gov的技术问题 需引以为戒
如何掌握单页面应用开发
若干优秀的UI设计原则
如何满足不断增长的应用需求
应用性能管理成熟度模型
我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。
我原创，你原创，我们的内容世界才会更加精彩！
