我通常使用这个约定：
CompanyName.ApplicationName.Functionality
e.g。
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会附加到命名空间。
我已经看到了很多命名约定标准，但似乎没有提到这个问题。
每种方法的优点和缺点是什么？
答案 0 :(得分：3)
遵循Microsoft创建的命名准则：
为命名空间选择的名称应指示命名空间中类型可用的功能。例如，System.Net.Sockets命名空间包含的类型使开发人员能够使用套接字通过网络进行通信。
命名空间名称的一般格式如下：
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
例如，Microsoft.WindowsMobile.DirectX。
使用公司名称作为前缀名称空间名称，以防止来自不同公司的名称空间具有相同的名称和前缀。
http://msdn.microsoft.com/en-us/library/vstudio/ms229026(v=vs.100).aspx
在这种情况下，我认为BusinessLogic或Dal只是层抽象而且实际上不属于命名空间。因此，我不会使用任何一个例子，只是
Acme.EmailService
这些额外的名称空间使得查找正确的接口/类更加困难。你还在使用多个组件，对吧？无论如何，您的不同图层将被分开（在程序集的帮助下）。
问问自己图层命名空间真正给你的是什么？每个命名空间中有多少个类？ 10岁以下？它是否能够 更难 或 更容易 来处理您的代码？
答案 1 :(得分：2)
首先，如果我有任何库/公共代码，它会进入非客户特定的命名空间（这里，CompanyName是我工作的地方）：
CompanyName.DB
CompanyName.Common
CompanyName.Web
等。
其次，如果是客户特定的，我使用ClientName.Application.Functionality表格。这是因为如果它不常见（因此会出现在前面提到的库和名称空间中），我相信功能属于到应用程序，而不是相反。
我的意见，显然;）
编辑：澄清，我使用ClientName作为特定客户端的顶级命名空间。我们与一些客户有多个项目，因此您最终可以：
ClientName.Common
ClientName.Application1
ClientName.Application2
等...
答案 2 :(得分：1)
我相信如果您有太多的子图层，使用第二个约定可能会搞砸。例如，我们的一个项目包含200多个项目，我选择按项目而不是功能对命名空间进行分组，因为功能属于应用程序，除了常见（非常常见）功能。
想想Framework，我们可能正在使用像System.Ui.Web这样的名称空间，它包含所有与ui相关的子名称空间，而不是我们当前的体系结构System.Web.Ui，它按平台/应用程序对名称空间进行分组。
我不相信有一个确切的事实，我相信有习惯，很难说服人们改变惯例。