dotnet中的命名空间命名约定

Question

我通常使用这个约定：

CompanyName.ApplicationName.Functionality

例如

Acme.EmailService
Acme.EmailService.Dal
Acme.EmailService.BusinessLogic
Acme.EmailService.BusinessLogic.ErrorHandling

但我目前在哪里工作，他们使用：

CompanyName.Functionality.ApplicationName

Acme.EmailService
Acme.Dal.EmailService
Acme.BusinessLogic.EmailService
Acme.BusinessLogic.EmailService.ErrorHandling

最后的命名空间对我来说有点奇怪。 它是businesslogic项目的子文件夹，因此默认情况下，foldername会附加到命名空间。

我已经看到了很多命名约定标准，但似乎没有提到这个问题。

每种方法的优点和缺点是什么？

Answer 1

遵循Microsoft创建的命名准则：

为命名空间选择的名称应指示命名空间中的类型可用的功能。 例如，System.Net.Sockets命名空间包含允许开发人员使用套接字通过网络进行通信的类型。

命名空间名称的一般格式如下：

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

例如，Microsoft.WindowsMobile.DirectX。

使用公司名称作为前缀名称空间名称，以防止来自不同公司的名称空间具有相同的名称和前缀。

在这种情况下，我认为BusinessLogic或Dal只是层抽象而且实际上不属于名称空间。 因此，我不会使用任何一个例子

Acme.EmailService

那些额外的名称空间使得更难找到合适的接口/类。 你还在使用多个组件，对吧？ 无论如何，您的不同图层将被分开（在程序集的帮助下）。

问问自己图层命名空间真正给你的是什么？ 每个命名空间中有多少个类？ 10岁以下？ 是否使代码更难或更容易 ？

Answer 2

首先，如果我有任何库/公共代码，它将进入非客户特定的命名空间（这里，CompanyName是我工作的地方）：

CompanyName.DB
CompanyName.Common
CompanyName.Web

等等

其次，如果它是特定于客户的，我使用ClientName.Application.Functionality表单。 这是因为如果它不常见（因此将在前面提到的库和命名空间中），我相信该功能属于一个应用程序，而不是相反。

只是我的意见，显然;）

编辑：澄清，我使用ClientName作为特定客户端的顶级命名空间。 我们与一些客户有多个项目，因此您最终可以：

ClientName.Common
ClientName.Application1
ClientName.Application2

等等...

Answer 3

我相信如果您有太多的子图层，使用第二个约定可能会搞砸。 例如，我们的一个项目包含200多个项目，我选择按项目而不是功能对命名空间进行分组，因为功能属于应用程序，除了常见（非常常见）功能。

想想Framework，我们可能正在使用像System.Ui.Web这样的名称空间，它包含所有与ui相关的子名称空间而不是我们当前的体系结构System.Web.Ui，它按平台/应用程序对名称空间进行分组。

我不相信有一个确切的事实，我相信有习惯，很难说服人们改变惯例。