C# 分区程序集和名称空间的策略提示

对于技术架构师来说，一个非常常见的复杂性是将应用程序划分为程序集和名称空间

• 程序集可以根据部署、性能和安全边界进行分区
• 名称空间可以根据逻辑应用程序边界进行分区

另外：名称空间可以跨越多个程序集

我曾经在一个项目中有过不好的经历，我们根据应用程序的逻辑单元对程序集进行了分区。这一决定最终得到了包含30或40个项目的解决方案文件！主解决方案文件加载时间约为5分钟！！！这最终是在浪费时间，pff

相反的场景是在真正需要时将所有代码保存在一个程序集和分区中

---

关于这个问题，您有其他的提示或最佳实践吗？

只有当我需要将代码重新用于两个不同的应用程序时，我才会将代码拆分为单独的程序集（基本上是这样）。因此，我从一个项目中的所有内容开始，当重用代码的需求变得明显时，我会创建一个新的程序集并移动代码（有时从一开始就很明显，例如，当您需要一个web应用程序和win forms做同样的事情时）

---

Re。名称空间，我更喜欢在程序集中对其进行很好的分区，这样就可以清楚地知道每个类属于何处以及它应该用于何处。

如果您想将源文件组合在一起以便于维护，您可以使用名称空间对类进行分区并使用文件夹。如果您有安全要求，并且某些程序集需要经过特殊处理，例如模糊处理，那么您可能需要将这些程序集分离到单独的项目中

---

重新可用性也是考虑逻辑单元是否需要得到自己的项目时需要考虑的因素，因为您可能需要另一个解决方案中的这个项目。

对我来说，对我来说工作得很好的是按代码类型进行大级别分组，但比您所分割的逻辑单元更大的级别。 比如说,

• 引擎-任何不可见的东西。支持类、基本基础结构代码。一切都与此有关
• EngineUI-依赖于引擎，显然用于UI，但不特定于任何一个应用程序
• EngineServer—依赖于（通常是web）服务器构建所使用的引擎
• AppCore-特定于应用程序的核心功能，无UI
• AppUI-特定于应用程序的UI
• AppClient-使用AppUI、AppCore、EngineUI和Engine。实际的客户端应用程序
• AppServer-使用AppServer、EngineServer和Engine。服务器应用程序

每个项目都有一个名称空间层次结构，有时我会发现将大量代码插入另一个程序集中是很有用的，但通常这些都可以使事情合理地组织和管理，即使涉及到数百个文件。太多的项目肯定是我尽量避免的。将这些项目保持在最低限度的一个好处是，它使在后续项目（如自动测试构建）中实际重用这些库变得更加容易

---

我不太担心从这些库中部署未使用的代码，因为我可以在最终生成时使用删除未使用的函数的方法，将文件大小保持在最小值。

我发现将名称空间组织到层次结构中，并使程序集名称与它们所贡献的子名称空间相匹配很有帮助。例如，一个名为Womble的项目将有一个顶级命名空间Womble，然后可能会有名为：

Womble.ClientLibrary.dll
Womble.Controls.dll
Womble.Util.dll
Womble.Interop.dll

在这里，外部Womble名称空间跨越多个程序集，但每个程序集都有一个唯一的子名称空间，只有它可以参与，您可以通过从末尾删除.dll来找到它。它使你更容易记住你需要参考的东西和找到的东西

对于大量的程序集，最终您不需要将它们全部保存在一个解决方案中。在大规模开发中，它有助于将大型产品分解为子系统，子系统本身可能由多个组件组成，每个子系统可能最终由单独的团队维护，并且可以拥有自己的解决方案文件。各个团队通过源代码管理相互“发布”新版本，将彼此视为第三方库

我不认为有一种硬性的方法来决定如何将软件分解成一个组件。这里有一个普遍的原则：因不同原因而改变的事物应该分开

非常大的项目可以从这样一个事实中获益：通过将事物放在单独的程序集中，您可以分别对它们进行修补。您可以为Womble.Interop.dll中的问题生成修补程序，然后分别为Womble.Controls.dll中的问题生成修补程序，并将两者提供给同一客户，这样，理论上，这两个程序集可以完全由单独的团队维护和支持，而不必直接协调他们的活动

---

单独的程序集还可以清晰地显示代码之间的依赖关系。您可以在一个非常高的层次上（仅查看引用列表）看到一段代码如何依赖于另一段代码，以及如何重用它。如果你把所有的东西都放在一个组件中，它可能是一个大的混乱，没有合理的模式。

动机

我之所以发布这个迟来的答案，是因为之前所有的答案都是更多的建议，而不是一致的最佳实践

由于多年来我一直在一个非常大的.NET项目中工作，唯一在战略和技术上都具有良好动机的一致的最佳实践是由独立团队提出的

简而言之

NDepend建议通常与您不根据体系结构构建组件的经验相一致。它还包含何时使用单独的程序集以及为什么使用这些程序集的注意事项。经验法则是使用结构化