良好的命名空间命名约定答案

【问题标题】：Good Namespace Naming Conventions良好的命名空间命名约定
【发布时间】：2009-02-25 18:59:42
【问题描述】：

我正在为 CRUD 业务应用程序创建一个类库。业务对象（以及相关的数据访问层对象）的主要“类别”是：

维护（用于与主数据库中的表（主列表）
事件（大多数对象与现实世界的事件有关）
搜索（明显）

截至目前，我的命名空间设置如下：

BusinessObjects.Maintenance.Contacts
BusinessObjects.Maintenance.Products
BusinessObjects.Maintenance.Classifications
.
BusinessObjects.Incidents.Contacts
BusinessObjects.Incidents.Products
BusinessObjects.Incidents.Classifications
.
BusinessObjects.Search.Contacts
BusinessObjects.Search.Products
BusinessObjects.Search.Classifications
.
Dal.Maintenance.Contacts
Dal.Maintenance.Products
Dal.Maintenance.Classifications
.
Dal.Incidents.Contacts
Dal.Incidents.Products
Dal.Incidents.Classifications
.
Dal.Search.Contacts
Dal.Search.Products

请注意，每个类都以相同的名称结束。

这种形式好吗？

此命名空间约定是否会引起任何问题？对查看/使用此代码的其他人有任何可能的混淆吗？

我确实意识到，在表单代码中，一个缺点是我必须使用名称空间限定所有对象。对我来说，这没什么大不了的。如果那是一个词，我通常更喜欢一点明确性。

【问题讨论】：

我想你想要“显性”这个词。 :)
为了简单起见，我更喜欢使用“Core”而不是“BusinessObjects”
好主意。我将更改它以缩短命名空间。

标签： language-agnostic namespaces theory

【解决方案1】：

反正我觉得没问题。不过，我会远离缩写词，这会让人感到困惑并迫使人们必须知道缩写词或查找它们。它们也变得不可读和不可言说。

"Lets take a look at the BusObjConfIntContYYYYmmdd package now..."

您可能会遇到的一个问题是名称存在细微差别。由于名字的长度可能是一个问题，你的眼睛可能会掩盖整个事情，只看到其中的一部分。会不会有这样的情况发生？：

BusinessObjects.Incidents.Classifications
BusinessObjects.Classifications.Incidents

或

BusinessObjects.Forms.ProjectManager.Exportable.Windows.XP
BusinessObjects.Forms.ProductManager.Exportable.Windows.XP

那个人为的例子可能会成为一个问题。

【讨论】：

【解决方案2】：

通常最好不要以实现的任何特定模式命名您的包，而是以它们所属的业务或功能域命名。

即：

Org.MyCompany.BusinessObjects.Maintenance.Contacts
Org.MyCompany.BusinessObjects.Incidents.Contacts
Org.MyCompany.BusinessObjects.Search.Contacts

改为：

Org.MyCompany.Contacts

其中将包含对“联系人”执行操作的类/接口/对象/任何内容。

【讨论】：

【解决方案3】：

我认为该项目将受益于一些缩写。当我过去遇到这样的问题时，我通常会花一些文档来解释一些用作命名空间的缩写。我通常将这些缩短的名称限制为 3-5 个字符。这不仅增加了表单代码中的一般代码可读性，而且我还发现较短的名称可以减少其他编码人员的混淆。

我希望这会有所帮助。归根结底，这真的取决于你团队的偏好......

【讨论】：

【解决方案4】：

在经历了很多之后，我们尝试保持命名空间的数量较少（对于一个非常大的项目来说少于几十个），并且命名空间的深度要短（少于 5 个左右）。从消费的角度来看（开发人员使用我们的代码库），必须跟踪包含少量类的大量命名空间是一种开销，几乎没有什么好处。

我们还根据使用情况将赞与赞分组。如果开发人员很可能总是将某些类与其他类一起使用，即使（在您的示例中）一个可能与维护相关而另一个不相关，如果它们在逻辑上、操作上或程序上相关，我们将它们放在同一个命名空间中.使用提供者模型将独立的功能（例如，特定于维护的逻辑）分解为另一个命名空间。由于开发人员不太可能需要修改提供程序包含的功能，因此需要在更深、独立的命名空间中进行修改。

【讨论】：

【解决方案5】：

您的命名空间层次结构看起来类似于称为嵌套泛化的条件。这是当你有派生多种不同方式的类时。

想象一个类层次结构如下：

class Vehicle 

class Car : Vehicle
class CarRed : Car 
class CarBlue : Car 

class Truck : Vehicle 
class TruckRed : Truck 
class TruckBlue : Truck

请注意，车辆可以是轿车或卡车。此外，车辆可以是红色或蓝色。这工作得非常好，但是当您想要添加新颜色或车辆类型时会出现问题，因为修改的负担会以二次方增长。

GOF 设计模式一书描述了这个问题 -- 特别是桥接模式。

虽然它没有专门解决关于命名空间的问题，但我的直觉告诉我情况是相似的。我想说，如果你能避免这种情况，那么你应该这样做。

【讨论】：

【解决方案6】：

还可以查看这篇 MSDN 文章以获取命名空间命名指南

命名空间的名称： http://msdn.microsoft.com/en-us/library/ms229026.aspx

【讨论】：

【解决方案7】：

我为每个库和每个可执行源代码集使用一个命名空间。名字总是很短。例如，在我目前正在处理的可执行文件中，我有：

ALib - 我的通用实用程序库
Mongo - 我的迷你 Web 服务器库
DBLite - 我的 SQLite3 包装器和简单持久层
Track1 - 可执行文件（实际上是几个可执行文件）

这似乎工作得很好。我发现应该避免非常复杂的命名空间方案，就像非常复杂、深层次的类层次结构一样。

【讨论】：