大型 C# 应用程序的命名空间组织概念 [关闭]

Question

我实际上正在开始一个全新的项目，其中我现在已经有很多项目。我要质疑的是，大多数人可能会以与构建项目层次结构相同的方式构建命名空间。

示例：

在一个 n 层应用程序中，您可能有一个可以包含三个模块的表示层

• 启动
• 核心
• 一些模块

“正常”命名空间现在可能如下所示：<CompanySpecific>.Presentation.<ProjectName>.<IndividualStuff>

这看起来不错吧？ 您完全可以像这样组织您的命名空间，但请考虑以下事项。

想象 Core 和 SomeModule 都会有 Windows 和 Controls 子命名空间。这意味着要使用所有控件和窗口，您可以适当地添加那些 using 指令：

using <CompanySpecific>.Presentation.Core.Windows;
using <CompanySpecific>.Presentation.Core.Controls;
using <CompanySpecific>.Presentation.SomeModule.Windows;
using <CompanySpecific>.Presentation.SomeModule.Controls;

您的命名空间越深，您需要包含的内容就越多。

所以你完全可以省略命名空间的项目部分。这将导致这些命名空间被 Core 和 SomeModule 扩展：

using <CompanySpecific>.Presentation.Windows;
using <CompanySpecific>.Presentation.Controls;

您真正可以访问哪些类取决于您的项目依赖关系，就像以前一样。

问题

您现在知道这会导致哪种问题。我不想更准确地说明这一点。

• 在命名空间中使用项目名称是否有意义？
• 您是否也按体系结构层对命名空间进行分组？ （就像我在演示文稿中所做的那样）
• 是否有其他标准可能有助于构建命名空间？
• 是否有任何已知的最佳实践可以做到这一点？ （不太平，也不太深）

Answer 1

首先，程序集的名称应该与命名空间相匹配。 JetBrains ReSharper 会通知您，而且很确定 FXCop 也会。

Microsoft 长期以来一直建议将命名空间命名为：

CompanyName.TechnologyName[.功能][.设计]
- more...

至今仍在使用。以 Microsoft Azure 为例：

Microsoft.Azure.Management.Compute

在命名空间中使用项目名称是否有意义？

是的，因为如果您不这样做，则意味着该程序集在公司范围内使用，但情况可能并非如此。如果一个程序集是特定于项目/技术的，那么就这样命名它。如果将上面的 Azure 示例称为 "Microsoft.Management.Compute"

您是否也会按体系结构层对命名空间进行分组？

我假设您的意思是程序集，因为您不想在同一个程序集中混合层代码。

是的。假设我有一个 WCF 和 EF 应用程序，那么我会有类似的东西：

Muppets.ToyShop.Contracts
Muppets.ToyShop.ClientProxies
Muppets.ToyShop.Services
Muppets.ToyShop.ServiceHost
Muppets.ToyShop.WebApp
Muppets.ToyShop.FatClient
Muppets.ToyShop.Datum

是否有其他标准可能有助于构建命名空间？

有时我喜欢将我的所有接口放入一个子 Interfaces 命名空间中。最近我不像 nDepend 那样皱眉。

是否有任何已知的最佳实践可以做到这一点？ （不太平，也不太深）

nDepend 之类的工具可以执行静态代码分析，如果所有类以一种方式相互引用并且由于耦合原因在同一个程序集中，它会建议您将子命名空间合并为一个。换句话说，它可以建议废除过多的命名空间。

nDepend 令人敬畏的依赖结构矩阵不仅向您展示了程序集中的哪些类型在其他地方使用，而且对于定位那些可能由于紧密内聚而应该展平的命名空间很有用。

Tell me more

另见

• nDepend