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

最后一个命名空间对我来说看起来有点奇怪。它是业务逻辑项目的子文件夹，因此默认情况下文件夹名称会附加到命名空间。

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

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

Answer 1

请遵循 Microsoft 创建的命名准则：

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

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

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

例如，Microsoft.WindowsMo​​bile.DirectX。

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

http://msdn.microsoft.com/ en-us/library/vstudio/ms229026(v=vs.100).aspx

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

Acme.EmailService

那些额外的名称空间只会让找到正确的接口/类变得更加困难。无论如何，您正在使用多个程序集，对吧？无论如何，您的不同层都会被分离（在组件的帮助下）。

问问自己层命名空间到底给了你什么？每个命名空间中有多少个类？ 10岁以下？它会让您的代码更难还是更容易？

Answer 2

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

CompanyName.DB
CompanyName.Common
CompanyName.Web

等等。

其次，如果它是客户特定的，我使用 ClientName.Application。功能形式。这是因为，如果它不常见（因此会在上述库和命名空间中），我相信该功能属于应用程序，而不是相反。

显然，只是我的意见；）

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

ClientName.Common
ClientName.Application1
ClientName.Application2

等等......

Answer 3

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

考虑一下框架，我们可能会使用像 System.Ui.Web 这样的命名空间，它包含所有与 ui 相关的子命名空间，而不是我们当前的体系结构 System.Web.Ui，它按平台/应用程序对命名空间进行分组。

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