轻松编程: 通过理顺软件的依赖关系提高应用程序灵活性

轻松编程: 通过理顺软件的依赖关系提高应用程序灵活性2011-10-24 msdn James Kovacs本文讨论:

紧密耦合体系结构的错误之处

测试和依赖关系灾难

依赖关系反转

依赖关系注入

本文使用了以下技术:

.NET Framework

几乎所有人都认为追求松散耦合设计不是明智之举。遗憾地是，我们所设计软件的紧密耦合程度通常都远远超过我们的预期。如何了解设计是否耦合紧密？可使用静态分析工具（如 Ndepend）来分析依赖关系，但了解应用程序中耦合程度最轻松的办法是尝试独立地实例化一个类。

从业务层中选取一个类（如 InvoiceService），然后将其代码复制到一个新的控制台项目中。尝试对它进行编译。您很可能会丢失某些依赖关系（如 Invoice、InvoiceValidator 等等）。将这些类复制到此控制台项目并重试。您又会发现缺少其他类。最终可执行编译时，您可能会发现新项目中已存在绝大部分基本代码。就像拉动毛线衫的一个松动线头就可以拆掉整件衣服一样。在您的设计中，每个类都直接或间接地与其他类耦合。更改此类系统的确非常困难，因为任何一个类中的更改都可能牵连到系统的其余部分。

解决这个问题的要点不是完全避开耦合，因为那是不可能的。例如：

string name = "James Kovacs";

我已将我的代码耦合到 Microsoft® .NET Framework 中的 System.String 类。这不妥帖吗？我不这样认为。System.String 类意外发生更改的可能性非常低，也少有可能因要求改变而必须修改我与 System.String 交互的方式。因此我对该耦合相当放心。此示例的用意在于指出并非一味地消除耦合，而是要了解它并确保明智地选用耦合。

以经常出现在许多应用程序数据层中的另一代码为例：

SqlConnection conn = new SqlConnection（connectionString）;

或者以下代码：

XmlDocument settings = new XmlDocument（）;settings.Load（"Settings.xml"）;

对于数据层将仅与 SQL Server® 交互或者始终从名为 Settings.xml 的 XML 文档中加载应用程序设置而言，您有多大把握？我们的目的不是构建一个可无限扩展但极其复杂、无法使用的泛型框架。而是与可逆性相关。您能轻松地改变设计决策吗？您的应用程序体系结构能否很好地响应变化？

为何我如此关注变化？因为就是这个行业中唯一不变的就是变化。需求、技术、开发人员以及业务都在变化。您有无做好应变准备？通过创建松散耦合设计，软件就可更好地响应许多时候无法预计的必然变化。