组件的松散耦合答案

【问题标题】：Loose Coupling of Components组件的松散耦合
【发布时间】：2011-02-22 01:07:12
【问题描述】：

我创建了一个提供消息、电子邮件和短信的类库（程序集）。该类库定义了一个接口 IMessenger，EmailMessage 和 SmsMessage 类都实现了该接口。

我看到这是一个通用库，它将成为我的基础架构层的一部分，并且可以/可以在任何开发中使用。

现在，在我的应用程序层中，我有一个需要使用消息传递组件的类，我显然想使用我创建的消息传递库。此外，我将使用 IoC 容器 (Spring.net) 来注入我的实现，即电子邮件或短信。

因此，我想针对我的应用层类中的接口进行编程，然后我需要从我的应用层类中引用我的消息类库吗？

这是否将我的应用程序层类与消息类库紧密耦合？

我应该在单独的库中定义接口 - IMessenger 吗？

或者我应该做点别的吗？

【问题讨论】：

标签： .net oop architecture

【解决方案1】：

这完全取决于您对 IMessenger 的未来计划。就我个人而言，我认为在同一个程序集中拥有接口以及一些示例实现并不是一件坏事。如果有人想提供 IMessenger 的新实现，他们将不得不在另一个程序集中进行，并且在引入您的程序集的过程中，他们将获得 EmailMessage、SmsMessage 等。对于轻量级程序集，我认为这没什么大不了的，因为它节省了您每次想要使用“接口”和“实现”程序集时都引用的工作。

如果您的实现类引用了与您的组织相关的其他代码或任何您不希望公开的代码，那么将 IMessenger 分离到自己的程序集中并根据需要分发它会更有意义。

【讨论】：

您如何对轻量级组件进行分类？通过它的物理大小（字节），如果是的话，什么是轻量级的？
本质上是物理大小或类数。我的意思是，如果您在很多应用程序中重用该程序集，最好不要引入很多不相关的业务对象、数据访问类等。但听起来这将是一个独立的库你在很多项目中使用。您的问题应该是，“我是否希望需要 IMessenger 的每个人都知道 EmailMessage 和 SmsMessage [并因此包括它们]，还是用户应该能够在不知道现有实现的情况下实现 IMessenger？[使用两个单独的程序集]。

【解决方案2】：

将应用程序层类引用（并因此耦合）到消息库并没有错。只要您的消息库是独立的并且不了解其用户就可以了。

此外，不要仅仅为了架构的事实而过度架构。它应该有目的，收益应该大于成本。

【讨论】：

我很高兴你这样做 :) 归根结底，这就是它的全部意义所在。
我不同意。有一个紧密的耦合，这不好。同样重要的是，您的应用程序不知道其协作者的实现。这不是过度架构，它们只是很好的设计原则。

【解决方案3】：

我对您问题的回答：

“因此，我想针对我的应用层类中的接口进行编程，然后我需要从我的应用层类中引用我的消息类库吗？”没有
“这是否将我的应用程序层类与消息类库紧密耦合？”是的
“我应该在单独的库中定义接口 - IMessenger 吗？”是的

如果您使用的是 IoC 容器，请注入依赖项，并且不要将您的应用与基础设施实现耦合。

我的实现是将 IMessenger 接口放在应用程序层，以允许我的应用程序对象与接口对话，无论其实现如何。我会在一个单独的程序集中发送一般的电子邮件和 SMS，它们实现了 IMessenger。显然，注入是由 IoC 容器执行的。

应用层不应该知道基础设施层。

这是一个看到这种设计的好页面：Hexagonal Architecture。

【讨论】：

感谢您的回答。如果 IMessenger 是在应用程序层中定义的，这是否意味着提供实现的程序集必须引用应用程序层中定义 IMessenger 接口的程序集？
@David：是的，具有实现的程序集必须引用公开 IMessenger 的程序集。依赖是倒置的（应用层不知道基础设施的东西），实现应该由 Spring.net 解决。
这基本上意味着 IMessenger 实现不能在不引用该应用程序的情况下在其他应用程序中重用
@Maxim Gueivandov：你是对的。您可以将 IMessenger 放在单独的程序集中，并让 App Layer 和 IMessenger 实现引用此程序集。