问题标签 [loose-coupling]

我似乎无法理解“松散耦合”的概念。我想“松散”这个词通常带有负面含义并没有帮助，所以我总是忘记松散耦合是一件好事。

有人会展示一些说明这个概念的“之前”和“之后”代码（或伪代码）吗？

最近我看到很多关于如何构建松散耦合应用程序的博客文章。在创建松散耦合的应用程序时，您最常使用哪些模式？依赖注入？控制反转？

我有一个几乎相同的数据库的两个版本。下面我创建了一个示例表来演示基本差异，即 ID 列已从 Integer Identity 更改为 GUID 并更新了各种属性，在示例中存档已替换为 readOnly 并隐藏：

旧版：

新版本：

我需要能够使用诸如 NHibernate 之类的 O/R 映射器来连接到这些数据库版本中的一个或其他。我希望能够通过配置文件中的设置告诉应用程序使用哪个版本。

我最初的计划是为业务逻辑创建一个通用接口，并使用 Unity 等 IoC 容器在配置文件中的相关具体类之间进行交换。

以下是我为测试该理论而创建的代码示例：

谁能建议这是否可行（特别是使用 Unity 和 NHibernate），如果可以，如何创建相关的 NHibernate 映射文件？

或者，任何人都可以使用任何其他方法或其他 IoC 和 O/R 映射工具（商业或开源）提出任何解决问题的方法吗？

非常感谢，

保罗

使用 IOC 容器时需要注意哪些事项（陷阱）？

您是否为域模型中的每个公共类实现了一个接口？优点和缺点？

更新：如果 Repositories 接口和域模型类在单独的程序集中定义，如果我们不为每个域类定义接口，就不会有循环依赖。

保持类松散耦合是编写易于理解、修改和调试的代码的一个重要方面——我明白这一点。然而，作为一个新手，几乎任何时候我都会超越我所苦苦挣扎的最简单的例子。

我或多或少地了解如何将字符串、整数和简单数据类型封装在它们自己的类中。然而，当我开始处理诸如富文本格式之类的信息时，事情变得非常复杂——除非我只使用组件中已经存在的各种方法。继续这个例子，假设我正在编写一些在 UI 中包含 RTF 备忘录组件的东西。在 Delphi 中，该组件具有用于执行诸如保存格式化文本之类的内置方法。此外，有时似乎唯一（或至少是最好的）处理 RTF 文本本身的方法是通过再次内置到组件中的方法。

当我已经有一个组件为我完成所有这些工作时，我将如何（或为什么）在另一个类中完成保存、加载和格式化文本的所有工作？

就我自己而言，我通常最终要么 (a) 做一些看起来比需要复杂得多的事情，重新发明已经存在的方法，或者 (b) 创建仍然彼此紧密耦合的糟糕的类。正如他们在非正式广告中所说的那样，“必须有更好的方法！”

我只是在概念上迷失了“更好的方式”是如何工作的。有什么想法吗？

早在 12 月，就有一篇帖子被回答为“可以使用具体类型 [用于简单对象]”。

但是我不断在示例项目中看到越来越多的带有接口的简单实体，甚至是我刚刚控制的非常大的企业应用程序（计数 89 个接口并且还在继续）。

是不是人们没有选择最好的方法，只是用“我的项目是松散耦合的！” 方法？

或者，我错过了什么。我可以对我拥有的 IService、IFactory 和 IRepository 实现使用具体类型进行单元测试（并且工作得很好）。我还在构建我的第一个“反腐败层”，用于从主域中抽象出许多这些 3rd 方工具。这个反腐败层有许多 Facades、Translators 和 Adapters - 所有这些都是松散耦合的（或计划是）。

那么，对于具有接口的实体，我是否遗漏了什么？

编辑：我还应该提到，我拥有的具有所有这些接口的企业应用程序具有零单元测试。哈哈

当我在做 TDD 时，它迫使我采用依赖注入原则，我最终得到了松散耦合的代码。

有人告诉我，很难理解具有松散耦合代码的应用程序。

你能告诉我松散耦合代码的优缺点吗？

我有一种情况，我试图让我的模型和实现尽可能松散耦合，但是我面临的情况是耦合可能比我想要的更接近。

我有一系列“模型”类，所有实现接口。此外，我还有“数据访问”类，它们提供了许多函数，其中之一是将整数查找值解码为其完整的“对象”表示。

在我的模型类中，我想提供对这些解码值的访问，而不需要模型知道数据访问类。

一个简化的例子是：

如何使Car该类能够将IMakeInfo对象提供给任何消费类而不直接使其知道 ResolveMake 类？在实际实例中，我使用的 Car 类与 ResolveMake 类不在同一个命名空间中，并且它不包含对它的任何实例的引用。

我的一些选择：

• 实现一个Car可以提供GetMakeInfo方法实例的委托。
• 某种依赖注入
• 将 Car 紧密耦合到 ResolveMake 并完成它。
• 还有其他选择吗？

欢迎任何建议！

松散耦合，高内聚，可维护的应用程序

这是我一遍又一遍听到的战斗口号。关于如何松散耦合组件有很多建议。

• 基于接口并注入所有依赖项
• 使用事件
• 使用服务总线
• 等等

然而，我觉得我从来没有真正听到过任何关于增加凝聚力的具体建议。有人可以提供吗？

你可以在那里开始回答，但我有一个具体的情况，我也想得到建议。

我有一个相当松散耦合的 C# Windows Forms MVP 应用程序，它的许多组件都基于接口，通过构造函数注入它们并使用控制反转容器 (Castle Windsor) 将它们组装在一起。

我会说它的架构非常好——它已经经历了几个大的变更请求并且很容易处理它们。总的来说，我对它非常满意，但我不能放弃一个挥之不去的怀疑，即它不是特别有凝聚力。作为唯一的开发人员，这对我来说不是问题，但我担心对于第一次进入应用程序的人来说，这会让人感到非常困惑。

让我举个例子 - A 公司使用该应用程序来填充和处理装满产品的外运卡车。这意味着有一个OutgoingTransactionInfo对象、一个OutgoingTransactionInfoControl（用于实际输入所述信息）、OutgoingTransactionValidator和OutgoingTransactionPersister。随着应用程序投入生产，我们也收到了处理传入事务的请求——这些事务附加了不同的信息、不同的验证以及不同的持久化方式。然后公司 B 也想将应用程序用于他们的事务处理，这个想法是相似的，但同样，信息、验证、持久性以及其他一些组件可能不同。

因为我的应用程序有一个很好的测试套件并且是松散的，所以我能够很容易地适应这些请求。但是，我认识到很容易意外地将其配置为无效状态。例如，您可以连接它以使用OutgoingTransactionInfo对象，同时使用IncomingTransactionValidator进行验证。如果差异很小，则错误甚至可能在一段时间内未被发现。

你对我有什么建议吗？您使用了哪些技术来降低此类风险？