.NET 项目架构

Question

我有一个哲学问题，也需要考虑性能影响。

我们正在设计一个新系统，其中包含许多彼此不相关的子服务，但有些子服务可能会相互使用(我们使用统一来避免任何解耦)。

我的主要问题是:

• 我们是否应该将它们分成单独的 DLL，其中每个服务都有自己的 dll(如 product.services.serice1.dll、product.services.serice2.dll 等)，或者我们应该将所有这些服务整合到一个单独的DLL，具有不同的 namespace ，将它们分开。 就性能而言，两者有什么区别吗？另外，社区(和微软)认可的最“可接受”的标准是什么？

谢谢

Answer 1

如果您的服务要一起使用，请将它们分组到同一个程序集中。我已经看到加载了无数 dll 的系统(以及其中包含无数项目的解决方案)，没有一个实例需要在其中挑选一个程序集而不是任何其他程序集。这并不妨碍您在命名空间中进行解耦和合理的分离。

就性能而言，加载的 dll 的数量并没有真正的影响(如果您保持理智并且不要使用数千个)，但是如果您坚持使用 VS 的默认行为，则对开发的影响是巨大的谁喜欢复制每个项目的 bin/debug 目录中的每个引用。在大中型解决方案(1000 个类)中，构建过程会更长，更令人沮丧。

将程序集视为一个部署单元。如果要一起部署东西，请将您的东西放在同一个程序集中。

作为一个警告，将项目拆分成太多的程序集是多么令人沮丧，请查看 NUnit 发行版。超过 30 种不同的 dll，有些你必须引用才能进行单元测试，有些你没有，你最终会寻找你需要的类型。