大型c＃应用程序的命名空间组织概念

Question

我实际上正在开始一个全新的项目，我现在已经拥有了很多项目。我所质疑的是大多数人可以按照建立项目层次结构的方式建立名称空间的做法。

实施例

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

• 启动
• 核心
• SomeModule

A＆＃34;正常＆＃34;命名空间现在看起来如下：<CompanySpecific>.Presentation.<ProjectName>.<IndividualStuff>

这看起来不错吗？ 你可以像这样完全组织你的命名空间，但请考虑以下几点。

想象一下，核心和 SomeModule 都会有Windows和Controls个子名称空间。这意味着要使用所有控件和Windows，您可以使用指令添加它们：

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;

您真正可以访问的哪些类依赖于您的Project-Dependencies，与以前一样。

问题

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

• 在命名空间内使用项目名称是否有意义？
• 您是否也可以通过Architecture-Tiers对命名空间进行分组？ （正如我在演讲中所做的那样）
• 是否有其他可能有助于构建命名空间的标准？
• 是否有任何已知的最佳实践来执行此操作？ （不太平，也不太深）

Answer 1

首先，程序集的名称应与名称空间匹配。 JetBrains ReSharper会对你发牢骚，并且非常肯定FXCop也会这样。

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

  

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

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

Microsoft.Azure.Management.Compute

  

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

是的，因为如果不这样做意味着程序集在公司范围内使用可能并非如此。如果程序集是项目/技术特定的，那么将其命名。如果它被称为“Microsoft.Management.Compute”

，那么上面的Azure示例会令人困惑

  

您是否也可以通过Architecture-Tiers对命名空间进行分组？

我假设你的意思是装配，因为你不想在同一个装配中混合层代码。

是。说我有一个WCF＆amp; 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的令人敬畏的依赖结构矩阵不仅可以显示程序集中的哪些类型在其他地方使用，而且可以用于查找那些由于紧密内聚而可能被展平的名称空间。

Tell me more

另见

• nDepend