分裂组件 - 找到平衡（避免过度杀伤）

Question

我正在编写一个广泛的组件基础架构，用于我的项目。 由于并非所有项目都需要创建所有组件，因此我一直在考虑将组件拆分为离散组件，以便开发的每个应用程序都只与所需的组件一起部署。

我假设创建程序集有一些存储开销（程序集的代码，包装内部的任何内容）。因此，对拆分装配所获得的优势必须有一些限制 - 在某一点上拆分装配比使其保持联合（存储方式和性能方面）更差。

现在，问题是：我如何知道何时拆分装配是一种过度杀伤？

P.S 我想除了存储开销之外还有其他的组件拆分开销。如果有人能指出这些开销，我们将非常感激。

Answer 1

拆分程序集确实存在其他开销：

• 编译时间越长（解决方案中的项目越多，需要的时间就越长）
• 部署噩梦 - 特别是对核心组件的更新
• 更多程序集最终可能会slowing您的应用程序

为什么需要将它们分开？为了使它们在逻辑上分开？如果这是原因，请使用命名空间而不是拆分程序集。

Answer 2

Robert C Martin（以SOLID原则而闻名）提供了一个包装经验法则，您可能会觉得有用：

“重复使用的颗粒是释放的颗粒。”

也就是说，在决定如何在包中分组时，将它们拆分成你想要使用它们的方式。因此，如果您想在程序集中使用一个类，则应该使用其中的大多数。如果项目中的所有内容都是出于同样的目的，那么为什么要拆分它们呢？

Answer 3

我不担心拆分组件的开销。它并不重要，任何性能损失都将超过应用程序开发过程的简单性。您需要考虑的是对程序集进行版本控制，以及当应用程序B需要部分应用程序A时，您将如何处理应用程序A的升级。没有快速解决该问题，如果您不小心，可能最终会为每个使用它的应用程序的每个程序集的内部分支。

Answer 4

嗯，这真的不是一个可以在逻辑上回答的问题 - 没有“规则”。尝试将子系统保留在seaprate程序集中。有时会出现技术原因/部署差异（assemb，y设计程序集 - 必须进入GAC才能找到设计人员）。

一般情况下，如果我找到我也在单独测试的逻辑子系统，我会将它们分开。请注意，“内部”访问仅适用于装配边框。因此，如果您有一个像DAL这样的子系统......将它放在一个单独的程序集中，允许它使用“实习”属性，并且不会受到项目其他部分开发人员的简单滥用。

另外，如果你更“正式”，不同的子系统将拥有不同的所有者/开发周期/项目经理。