.NET项目体系结构 我有一个哲学问题，也需要考虑性能的影响。

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

我的主要问题是：

• 我们应该将它们分成单独的DLL，其中每个服务都有自己的DLL（如product.services.serie1.DLL、product.services.serie2.DLL等），还是应该将所有这些服务合并到一个单独的DLL中，并使用不同的名称空间来分隔它们。 就性能而言，两者有什么区别吗？另外，社区（和微软）认可的最“可接受”的标准是什么

---

感谢

我个人，我会将它们划分为独立的DLL项目，以简化开发、测试和维护。

当它们是独立的“服务”时，我更喜欢将它们划分为独立的项目和程序集

如果将所有内容放入单个程序集中，则希望使用任何服务的任何客户端都将自动加载整个程序集。通过分解它们，您可以在不同的客户端应用程序之间降低内存使用率，并且只根据需要加载内容。从技术上讲，加载一个程序集要比加载多个程序集快，但如果您在感知性能方面懒得加载程序集，则加载速度不会快

---

加载程序集后，性能应该相同。

部署在这里是一个大问题。如果所有这些功能都部署在一台机器上，我建议使用一个.dll，使用不同的名称空间进行行为分离。单个.dll将避免将来出现许多与.dll之间兼容的问题，并大大简化部署和安装

---

保罗

不要过早优化。我会分离名称空间，直到您需要将它们作为本地优化连接起来。

我喜欢将大型系统开发为几个独立的程序集/DLL，以促进体系结构的存在。之后，如果需要，您可以在部署前将功能重新打包到单个程序集中。

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

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

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

---

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

.NET程序集代表了一个物理工件，用于打包您永远不应该用于架构的东西。换句话说，使用尽可能少的程序集，最好只使用一个.NET程序集。我建议阅读如何在程序集、命名空间、层和组件中对代码进行分区

• （8页）
• （7页）

---

每次调用DLL中的函数时，DLL都会加载。大型dll不是一个好方法。使用更小的DLL，这将提高您的性能。

我不得不笑了。这是一个复杂的问题，有很多优点和缺点。这是一个非常复杂的问题。我只是从一个非常普遍的案例来讨论这个问题。事实上，他特别提到通过多个名称空间支持多个类型，这让我相信在“服务”中存在一些分离的关注点，在这种情况下，分离的程序集通常是最好的方式；但你们中的任何一个人都在考虑加载多个（超过20个）不同dll的效果，而不是单个的大dll。我想知道除了延迟加载的优点（现在我们忽略了部署困难）之外，是否还有加载大量DLL的风险？谢谢嗨，伙计们，感谢所有的投入；但你们中的任何一个人都在考虑加载多个（超过20个）不同dll的效果，而不是单个的大dll。我想知道除了延迟加载的优点（现在我们忽略了部署困难）之外，是否还有加载大量DLL的风险？谢谢首次访问时加载dll。因此，如果系统在启动时经历了初始化阶段，您可以调用dll来强制加载它们。这将避免“运行时”的性能延迟。20 dll==dll地狱。如果可能的话，我会合并。它们只是有不同的性能特征。一个大型程序集加载所需的总时间较少，但它会同时发生，因此用户（或客户机系统，如果他们对时间敏感的话）更容易感觉到它。“多个程序集”方法需要更多的总时间来加载（如果您全部加载），但时间是分散的-因此每个加载事件不太可能产生重大影响。根据我的经验，单独的程序集并不总是简化这些事情-往往恰恰相反。（特别是在部署中）您能详细说明一下吗？我也喜欢这种方法。使用多个程序集意味着您倾向于考虑每个程序集（及其类型）与其他程序集（分层等）的关系。一旦您有了满意的东西，您就可以进行整合