我通常将项目划分为多个层，即表示层、业务逻辑层和数据逻辑层。有时我会使用名称空间来分隔层，有时我会有三个单独的DLL（使用层）。
我看到开发人员将层划分为多个DLL。例如，我曾经看到一个业务逻辑层，它有一百多个不同的项目文件，因此也有一百多个不相同的DLL。MSDN文档还显示，.NET框架包含多个DLL，例如mscorlib等
我相信，拥有单独DLL背后的原因是，它最大限度地减少了内存占用，还允许多个开发人员处理不同的项目，例如，一个团队可以处理一个项目，另一个团队处理另一个项目等。
我在一个由两名开发人员组成的团队中工作。开发人员在决定拆分为单独的DLL时使用什么标准？
将层分离为多个DLL的理由是什么？
这样做有多种原因。
- 它增加了隔离，这可以帮助编译器防止您混淆问题。如果不显式添加引用，就不能"意外"地在其他DLL中使用内部类型，这允许编译器帮助您保持代码的整洁
- 如果在运行时不使用程序集，则不会加载该程序集。这样可以使内存占用空间更小。（但是，如果使用所有程序集，则没有帮助）
- 它在API和项目中提供了逻辑分离，这有助于代码的组织和可维护性。请注意，太多的项目和太少的项目一样糟糕（有时甚至更糟），然而，因为许多项目增加了复杂性，这可能没有好处
将代码分离成多个程序集有很多原因，其中一些原因比其他原因更具技术性。程序集可以用于代码的逻辑分组，就像名称空间一样，事实上，一种常见的模式是将大型名称空间（关注点）分离为该名称空间的单独程序集。但这个原因绝对不是使用多个程序集的最佳理由。
代码重用就像是将代码放入不同程序集的首要因素。例如，您可能有一个控制台应用程序，中的所有代码都是编译的一个执行文件。稍后，您决定为同一应用程序创建一个web应用前端。与其将核心代码从控制台应用程序复制到web应用程序，不如将解决方案重构为三个项目：代码库（主要实现）、控制台应用程序（已经存在）和web应用程序。控制台应用程序和web应用程序项目/程序集将引用类库项目/程序集中，并且主代码在两个实现中重复使用。请注意，这过于简单化了。
将代码分离为多个程序集以在管理依赖关系时分离关注点的另一个原因。在这种情况下，您可能有需要引用面向web的依赖项（其他程序集）的代码，而您可能不想在核心应用程序程序集中引用这些依赖项。这样做是为了在不需要时重用核心程序集，而不需要通过将应用程序分解为其他程序集/项目来获得不必要的依赖项。
另一个原因是为了促进大型团队的并行开发，其中子团队可能各自处理不同的程序集，这有助于减少处理应用程序不同问题的开发人员之间的"冲突"次数。