Dotnet中的命名空间命名约定

Question

4

我通常使用这种约定：

公司名称.应用程序名称.功能

例如：

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项目的子文件夹，因此默认情况下将文件夹名称附加到命名空间。

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

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

- Joe Small

3个回答

2

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

CompanyName.DB
CompanyName.Common
CompanyName.Web

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

仅代表我的观点，当然 ;)

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

ClientName.Common
ClientName.Application1
ClientName.Application2

etc...

- Moo-Juice

是的，这通常是我所做的。我从来没有遇到过问题，但我想知道是否有什么我错过的东西使第二种方法更有益。 - Joe Small

1

我认为如果你有太多的子层，使用第二种约定可能会搞乱事情。例如，我们的一个项目包含超过200个项目，我选择按项目分组命名空间，而不是按功能分组，因为功能属于应用程序，除了常见（真正常见）的功能。

想想框架，我们可能会使用像System.Ui.Web这样的命名空间，其中包含所有与UI相关的子命名空间，而不是我们当前的架构，System.Web.Ui，它按平台/应用程序分组命名空间。

我不相信有确切的真理，我相信有习惯，很难说服人们改变惯例。

- Kadir Sümerkent

一个解决方案里有200个项目？编译的时候你是去吃午饭了吗？重构一定很有趣！ ;) - jgauffin

我们使用专用的构建服务器，我向您保证，完整的构建需要一辈子 :) - Kadir Sümerkent

重构必须是有趣的！这给无畏的重构带来了新的意义。 - kheit

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- jgauffin · Accepted Answer

遵循微软创建的命名指南：

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

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

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

例如，Microsoft.WindowsMobile.DirectX。

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

在这种情况下，我认为BusinessLogic或Dal只是层抽象，真正不属于命名空间。因此，我不会使用你提供的任何示例，只需...

Acme.EmailService

那些额外的命名空间只会让你更难找到正确的接口/类。无论如何，您都将使用多个程序集，对吧？您的不同层将被分开（借助程序集的帮助）。

问问自己层命名空间真正给了你什么？每个命名空间中有多少个类？小于10个吗？这会使您的代码更加“难”或“易”于使用？