.net - 许多-'small'组件的特定缺点？

Question

我正在计划进行一些工作，以将Dependency Injection引入当前的大型单片库中，以期使该库更易于单元测试，更易于理解，并且可能更灵活。

我决定使用NInject，我真的很喜欢Nate的座右铭:“做一件事情，做得好”(改述)，在DI的背景下，它似乎特别好用。

我现在想知道的是，是否应该将当前的单个大型装配体拆分为多个具有不相交特征集的较小装配体。这些较小的程序集中的某些程序集将具有相互依赖关系，但它们之间的相互依赖关系却远非如此，因为代码的体系结构已经很松散地耦合了。

请注意，这些功能集也不是小事，它们本身也不是很小...它涵盖了客户端/服务器通信，序列化，自定义集合类型，文件IO抽象，通用例程库，线程库，标准日志记录等内容。

我看到一个先前的问题:What is better, many small assemblies, or one big assembly?种解决了这个问题，但是粒度似乎更精细，这使我想知道那里的答案是否仍适用于这种情况？

同样，在接近该主题的各种问题中，一个常见的答案是，“装配过多”装配会导致未指定的“疼痛”和“问题”。我真的很想具体了解这种方法可能带来的不利影响。

我同意在只需要1个组件的情况下添加8个程序集是一件“痛苦的事”，但是对于每个应用程序都必须包含一个大型的整体库也不是完全理想的……加上8个程序集只是您要做的事情一次，所以我对这个论点几乎没有同情心(即使我起初可能会和其他所有人一起抱怨)。

附录:
到目前为止，我还没有找到针对较小的程序集的令人信服的理由，所以我认为我现在将继续进行，好像这不是问题。如果有人能用可验证的事实想到充分可靠的理由来支持它们，那么我仍然会非常有兴趣了解它们。 (我会尽快添加赏金以提高知名度)

编辑:将性能分析和结果移到单独的答案中(请参见下文)。

Answer 1

我将给您一个真实的示例，其中许多(非常)小的程序集的使用产生了.Net DLL Hell。

在工作中，我们有一个庞大的本地开发框架，该框架根深蒂固(.Net 1.1)。除了常用的框架类型管道代码(包括日志记录，工作流，排队等)之外，还存在各种封装的数据库访问实体，类型化的数据集和一些其他业务逻辑代码。我并没有参与该框架的最初开发和后续维护，但确实继承了它的使用。正如我所提到的，整个框架产生了许多小的DLL。而且，当我说很多的时候，我们说的是100以上-而不是您提到的8点左右。更复杂的问题是，这些程序集都经过了简单的签名，版本控制，并出现在GAC中。

因此，快进了几年，随后又进行了许多维护，结果是，对DLL及其支持的应用程序的相互依赖造成了严重破坏。在每台生产机器上，machine.config文件中都有一个巨大的程序集重定向部分，该部分确保无论请求什么程序集，Fusion都会加载“正确的”程序集。这源于重建依赖于已修改或升级的每个依赖框架和应用程序程序集所遇到的困难。 (通常)会竭尽全力确保在修 retrofit 配时不会对装配进行重大更改。装配被重建，并在machine.config中创建了新的或更新的条目。

我要停下来听听巨大的collective吟声和喘息声!

这种特殊情况是不采取行动的后代。确实，在这种情况下，您将陷入一种完全无法维护的情况。我记得我刚开始使用它花了2天的时间就可以针对该框架进行开发，以解决我的机器问题-解决了我的GAC和运行时环境的GAC之间的差异，machine.config程序集重定向，由于编译时版本冲突由于直接引用组件A和组件B而导致错误的引用，或者更可能的版本冲突，但是组件B引用了组件A，但是版本与我的应用程序的直接引用不同。你明白了。

这种特定情况的真正问题是程序集的内容过于精细。而且，这最终导致了相互依存关系的纠结。我的想法是，最初的架构师认为这将创建一个高度可维护的代码系统-只需重建对系统组件的很小的更改。实际上，事实恰恰相反。此外，对于已经在此处发布的一些其他答案，当您达到如此数量的程序集时，加载大量程序集确实会导致性能下降-肯定是在解析过程中，我想，尽管我没有经验证据，但在某些极端情况下，运行时可能会受到影响，特别是在反射可能起作用的情况下-在这一点上可能是错误的。

您可能会鄙视我，但是我相信程序集存在逻辑上的物理分隔-当我在这里说“程序集”时，我假设每个DLL一个程序集。归结为相互依赖。如果我有一个依赖于程序集B的程序集A，我总是问自己是否需要在不使用程序集A的情况下引用程序集B。或者，这种分离是否有好处？通常，查看如何引用程序集通常也是一个很好的指标。如果要将大型库划分为程序集A，B，C，D和E。如果90％的时间引用了程序集A，因此，您始终必须引用程序集B和C，因为A依赖于它们，那么将程序集A，B和C组合在一起可能是一个更好的主意，除非有一个令人信服的论点允许它们保持分离。 Enterprise Library是经典的例子，您几乎总是要引用3个程序集才能使用库的一个方面-但是，对于Enterprise Library，它具有在核心功能和代码之上构建的能力重用是其架构的原因。

看架构是另一个好的指导原则。如果您有一个很好的干净堆叠的体系结构，其中您的程序集依赖项为堆栈形式，请说“垂直”，而不是“web”，当您在各个方向上都具有依赖项时便开始形成“web”，然后分离程序集在功能边界上有意义。否则，请考虑将事物整合为一体或进行重新架构。

无论哪种方式，祝您好运!