接口在多层应用程序中属于什么位置答案

【问题标题】：Where do interfaces belong in a multitier application接口在多层应用程序中属于什么位置
【发布时间】：2011-01-19 19:27:01
【问题描述】：

假设您有一个三层应用程序，其中包含用于一个简单应用程序的 UI、服务和存储库层，比方说保存地址。

如果 AddressService 有一个接口 IAddressService，那么该接口属于哪里？我知道“在地址服务中”似乎是一个显而易见的答案，但如果它在地址服务中，它似乎会破坏具有接口的意义，这样只要实现了 IAddressService，任何服务库都可以被交换。

（特别是在 .net 问题空间中，但它可能更通用，因此它被标记为架构）

【问题讨论】：

【解决方案1】：

地址服务程序集是它的正确位置。

如果它在地址服务中似乎会打败具有这样的接口，任何服务库可以换成只要它实现了 IAddressService

接口的重点是使调用者能够交换替代实现。提供一个具体的实现（或多个实现，就此而言）根本不会干扰。

我唯一会制作一个纯接口程序集是在我不提供任何实现的时候。

【讨论】：

对于大多数单个团队项目来说，这不会使（抢先式）创建接口变得多余，因为您可以延迟创建接口直到需要它，或者事后实施成本显着比我看到的 find-replace 高？
这取决于您所说的“需要接口”是什么意思。（这并不是使用单个程序集的真正结果。）通常有充分的理由编写接口而不是具体对象：请参阅stackoverflow.com/questions/48605/…、stackoverflow.com/questions/1970806/coding-to-interfaces 和 stackoverflow.com/questions/363295/…，所有这些都提供了可靠的信息和封面对此有相当多的意见。

【解决方案2】：

将它们放在一个单独的程序集中，如AddressService.Interfaces 或AddressService.Contracts，由所有三层共享。

【讨论】：

【解决方案3】：

我倾向于将它们放在子命名空间/目录下的相关程序集中。

例如，如果我有一个客户程序集，那么 ICustomerRepository 或 ICustomerAddressRepository 等将归入

..Customers.Interfaces.ICustomerRepository

【讨论】：

【解决方案4】：

我习惯将服务接口放在一个程序集中，将实现放在另一个程序集中。我在 .NET 中从来不需要它，但我还是这样做了，我认为这是一种将 UI“或其他 API 客户端”与服务实现分离的方法。

我需要在 Java 项目中进行这种分离，其中小程序必须调用 Web 服务；因此，只有带有接口的 jar 被发送到浏览器。如果 jar 还包含实现，那将是一个沉重的小程序。

【讨论】：