.NET项目架构

Question

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

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

我的主要问题是：

• 我们应该将它们分解为单独的DLL，其中每个服务都有自己的dll（如product.services.serice1.dll，product.services.serice2.dll等），或者我们应该将所有这些服务合并为一个DLL，具有不同的名称空间，在它们之间分开。 它的性能，这两者有什么区别？此外，社区（和微软）认可的最“可接受”的标准是什么？

由于

Answer 1

如果您的服务要一起使用，请将它们分组到同一个程序集中。我已经看到了带有zillions dll的系统（以及带有zillions项目的解决方案），而没有一个实例需要樱桃选择一个组件而不是其他任何组件。这并不妨碍您在命名空间中进行分离和理智的分离。

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

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

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

Answer 2

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

保

Answer 3

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

Answer 4

就个人而言，我将它们分成独立的DLL项目，以简化开发，测试和安装。维护。

Answer 5

当他们是独立的“服务”时，我更倾向于将它们分成单独的项目和程序集。

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

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

Answer 6

不要过早优化。我将命名空间分开，直到您需要将它们作为本地优化加入。

Answer 7

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

• Partitioning code base through .NET assemblies and Visual Studio projects（8页）
• Defining .NET Components with Namespaces（7页）

Answer 8

每次调用函数时都会加载dll。一个大dll不是一个好方法。使用较小的dll，这会增加你的性能。