在哪里将接口放在基于组件的架构中？

Question

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

极端解决方案将是：

• 所有人都在同一个集会中（并且你走了）
• 每个界面的一个程序集

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

特别是，我正在寻找KILLER的论点，不要采用上面的两个极端，显然是替代的approchaes。

任何意见赞赏。

Answer 1

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

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

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

Answer 2

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

任何“常见”数据类型都应与组件分开存在（可能在“公共”或“共享”组件中）。

Answer 3

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

然而，一个快速的轶事，

我亲眼看到整个解决方案随着功能特定组件的激增而爆炸。我也看到了单片方法。重申：你想要介于两者之间。

在我的个人项目中，我使用了大量的依赖注入[DI]和Inversion of Control [IoC]，并利用Castle Windsor Container来完成繁重的工作。我还早期确定哪些组件需要“广泛”范围，哪些组件不需要曝光。例如，服务[比如容器本身或事件代理]将被视为“广泛”，因为在整个应用程序中可能有许多此服务的消费者。隔离的组件[比如特定于业务的日期格式化程序] 不是广义的，因为除了特定的业务外，没有人有兴趣直接使用它。

广泛的接口，我会放在一个单独的SomeProductName.Interfaces程序集中。

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

汇编只是源组织的物理表示 - 它们实际上并不意味着它们本身的任何东西[即整体混合，虽然令人作呕，但在功能上等同于组织良好的解决方案和每个界面噩梦的令人不安的项目]。

组织惯例只有在为消费者服务时才有用[你！开发商！]

Answer 4

简而言之 如果接口是共享的，则必须将它们分组到一个公共程序集中，否则它们必须位于组件接口程序集中。

更详细一点 如果其中一个标准化（即共享）接口发生更改，无论您将其置于何处，您都必须更改实现它的所有组件，无论该接口是在公共组件中还是在组件中。 因此，选项1没有特定的缺点，即使如您所说，您可能只需要更改一个界面。 另一方面，通过复制每个组件中的公共接口会有一个缺点，请参阅标准冗余问题。

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

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

Answer 5

我使用尽可能少的装配，旨在单个装配，同时隔离域的易失性区域。当多个程序集明显合适或需要时，我会尽力将同时更改的接口分组到相同的程序集中。

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

Answer 6

您不能将接口分组到功能/域区域吗？通过这种方式，您可以在中间某处获得解决方案。如果没有，我会将所有常见接口放入一个程序集中。

Answer 7

这取决于每个界面的目的：

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

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

如果界面的目的是在一组替代供应商和一组替代消费者之间定义标准协议，那么界面就是独立的。

最后，如果将接口用作降低复杂性的一般方法，则它们通常由消费者拥有，并且应尽可能狭窄地定义，以便每个接口在特定需求上下文中支持消费者的需求。