在决定如何将应用程序分区为程序集时，最重要的考虑因素是什么？为方便起见，有些人只为每个唯一的命名空间（或者每个根命名空间）创建一个程序集吗？或者每个应用层一个（如演示文稿，商业/服务，数据）？或许更微妙，将整个模型放在一个组件中？这有什么关系真的很重要吗？
如果组件太多会减慢速度，那么应用程序应该具有临界质量或“好”数量的程序集吗？同样，单个组件太大时是否存在临界点，大型组件是否也会影响性能？
我知道这当然取决于具体的应用程序 - 所以我主要对一般指导方针感兴趣，以及在决定时使用什么标准。
谢谢！
（虽然在我的特定情况下，如果有人想对它发表评论，我正在构建一个WCF服务，其下面有一个业务和DAL层，以及一个使用该服务的网站。我传统上创建了许多较小的服务程序集，但现在我认为“Web”，“服务”，“模型”和“数据”（对于存储库等）的简单性看起来非常吸引人.Web引用仅服务，服务引用仅模型，模型引用数据只是。不确定它有多重要。）
答案 0 :(得分：1)
对我而言，我将一些代码分离为dll的主要原因是：
如果你需要其中一个，你应该考虑制作一个dll
在缺点方面，你需要解决一些棘手的周期性依赖（通常使用回调来完成）
答案 1 :(得分：1)
每层一个，一个用于任何“从上到下”应用程序特定的东西（可能是模型）和一个用于“常用工具”对我来说似乎是合理的。在层之间拆分的一个好处是，internal类型和方法等只能在它们的层中可见，这可以很好地帮助封装。
我已经看到了远太多项目的各种应用程序 - 它很快变得笨拙，特别是当你用单元测试加倍项目时。
答案 2 :(得分：1)
我倾向于选择垂直分割的一个/层，一旦代码库开始增长，我就会看到水平分割，通常围绕特定的业务功能块。例如，如果我的持久层与＆gt;交谈20个左右的表格，我想把它拆分下来，知道在哪里拆分是一种黑色艺术，它具有高度的领域和项目特定性。
我使用的经验法则是，我可能会在其他地方重复使用哪些合理的类。刚刚在我自己的代码库中完成了这个过程，有趣的是，有多少其他东西成为重新分解为基础类，抽象类或接口类的明确候选者，而它们又被推入更低级别的通用程序集。