Effective C# 原则32：选择小而内聚的程序集

核心提示： 我经常程序集和二进制组件类似的看作是Lego，你可以很容易的抽出一个Lego然后用另一个代替，Effective C# 原则32：选择小而内聚的程序集(3)，同样的，对于有相同接口的程序集来说，性能的损失是其次的，C#和.Net的设计是以组件为核心思想的，你应该可以很容易的把它抽出来然后用

我经常程序集和二进制组件类似的看作是Lego。你可以很容易的抽出一个Lego然后用另一个代替。同样的，对于有相同接口的程序集来说，你应该可以很容易的把它抽出来然后用一个新的来替换。而且程序其它部份应该可以继续像往常一样运行。这和Lego有点像，如果你的所有参数和返回值都是接口，那么任何一个程序集就可以很容易的用另一个有相同接口的来代替(参见原则19)。

更小的程序集同样可以让你对程序启动时的开销进行分期处理。更大的程序要花上更多的CUP时间来加载，以及更多的时间来编译必须的IL到机器指令。应该只在启动时JIT一些必须的内容，而程序集是整个载入的，而且CLR要为程序集中的每个方法保存一个存根。

稍微休息一下，而且确保我们不会走到极端。这一原则是确保你不会创建出单个单片电路的程序，而是创建基于二进制的整体系统，而且是可重用的组件。不要参考这一原则而走到另一个极端。一个基于太多小程序集的大型应用程序的开销是相关的。如果你的程序使用了太多的程序集，那么在程序集之间的穿梭会产生更多的开销。在加载更多的程序集并转化IL为机器指令时，CLR的加载器有一点额外的工作要完成，那就是调整函数入口地址。

同样，以程序集之间穿梭时，安全性检查也会成为一个额外的开销。同一个程序集中的所有的代码具有相同的信任级别(并不是同样的访问级别，而是可信级别)。 无论何时，只要代码访问超出了一个程序集，CLR都要完成一些安全验证。程序花在程序集间穿梭的时间越少，相对程序的效率就更高。

这些与性能相关的说明并没有一个是劝阻你把一个大程序集分离成小程序集的。性能的损失是其次的，C#和.Net的设计是以组件为核心思想的，更好的伸缩性通常更有价值。