将接口放在基于组件的体系结构中的位置？

Question

在基于组件的架构中，大量解耦组件通过一组标准化接口进行通信 - 有没有关于何处存储/如何对接口进行分组的指导原则？

极端的解决办法是：

• 都在同一组件（和您去）
• 一个组件为每个接口

这两个选项的似乎是错误的我 - 首先不够灵活（例如，如果你只想改变一个界面），第二个是另一个极端，这可能会很快升级到维护噩梦。

特别是，我在寻找KILLER的论点，不采用以上的两个极端和明显的替代认同。

任何意见赞赏。

Answer 1

简而言之 如果接口共享那么他们有在一个共同的组件被分组，否则必须在组件接口组件。

在稍微详细 如果标准化的一个（即共享）接口改变无论你在哪里把它，你将不得不改变所有正在实施它的组件，该接口是在一个共同的组件或者组件之一。 因此，没有特定于选项1的缺点，即使如您所说，您可能只需更改一个界面即可。另一方面，通过在每个组件中复制通用接口，您将会遇到缺点，请参阅标准冗余问题。

这不是一个特别的建议，而是从你选择（明智地）具有标准化接口的那一刻起的一个自然选择。你努力识别它们，你发现它们是标准的，现在你将它们分组。

如果实现这些通用接口的组件还有其他一些临时接口，那么这些接口必须位于组件组件中，因为它们不应该暴露给有权访问公共组件的其他组件。

Answer 2

您通常会创建某种形式的“通用”库，架构中的所有组件都必须引用该库。这就是所有共享接口，枚举等被定义和分组的地方。

因此，创建扩展或适合框架的库的第一步是引用Common.DLL。然后，您可以在该特定模块中实现您需要的任何一组接口。

您所描述的极端解决方案确实非常极端。第一个将会非常不灵活，基本上阻碍了扩展你的框架的能力。第二个是非常灵活的，但是将你的项目淹没在单一接口DLL的恼人的汤中。

Answer 3

我使用尽可能少的组件，针对单个组件，同时隔离域的易失性区域。当多个组件明显适合或需要时，我尽我所能将接口同时更改为相同组件。

最近有关于维护多个程序集的成本的一些很好的讨论。 This article特别擅长描述多个程序集的缺点，观察它们在开发时，编译时，部署时间和运行时如何增加成本。

Answer 4

你不能将接口分组到功能/域的区域吗？这样你就可以在中间某处找到解决方案。如果不是，我会把所有常见的接口放到一个组件中去。

Answer 5

IMO组件的接口应与组件一起存在 - 可能位于组件特定的接口组件中。

任何“通用”数据类型应与组件（可能位于“公用”或“共享”组件中）分开存放。

Answer 6

所有非常好的回应。我想提倡“适度”的普遍共识。

但是快速轶事，

我亲眼看到整个解决方案与爆炸的特定功能组件的激增。我也看到了单一的方法。重申：你需要介于两者之间的东西。

在我个人的项目中，我使用了大量的依赖注入[DI]和控制反转[IoC]，并利用Castle Windsor容器做了很多繁重的工作。我还会尽早确定哪些组件需要“广泛”范围，哪些组件不需要暴露。例如，一个服务[比如说容器本身或者一个事件代理]将被认为是“广泛的”，因为整个应用程序中可能会有很多这种服务的消费者。由于没有人有兴趣直接使用它，除了它所特有的业务以外，一个被隔离的组件（比如说一个特定于业务的日期格式化程序）将不会是而是。

宽泛的接口，我会放在一个单独的SomeProductName.Interfaces大会。

业务特定的接口可以放置在它们自己的面向功能的程序集SomeProductName.SomeStuffForAlice和SomeProductName.SomeStuffForBob中，通常与其实现相同的库。

组件只是源组织的物理表示 - 它们实际上并不意味着任何内容和它们自己[即单一的混搭，虽然令人费解，功能上等同于组织良好的解决方案和每个界面噩梦的令人不安的项目] 。

组织公约只有在它为消费者服务时才有用[你！显影剂！]

Answer 7

这取决于每个接口的目的：

如果接口的目的是定义的一组替代供应商的和单个消费者之间的标准协议，接口被消费者所拥有。

如果接口的目的是定义单个供应商和一组替代消费者之间的标准协议，则该接口由供应商拥有。

如果接口的目的是要在一组替代供应商和一组替代消费者之间定义一个标准协议，那么接口就是它自己的。最后，如果接口被用作降低复杂度的一般方法，它们通常由消费者拥有，并且应该尽可能窄地定义，使得每个接口在特定的需求上下文中支持消费者的需求。