3

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

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

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

  • BusinessObjects.Maintenance.Contacts
  • BusinessObjects.Maintenance.Products
  • BusinessObjects.Maintenance.Classifications
  • .
  • BusinessObjects.Incidents.Contacts
  • 业务对象.事件.产品
  • 业务对象.事件.分类
  • .
  • BusinessObjects.Search.Contacts
  • BusinessObjects.Search.Products
  • BusinessObjects.Search.Classifications
  • .
  • Dal.Maintenance.Contacts
  • Dal.Maintenance.Products
  • Dal.维护.分类
  • .
  • Dal.Incidents.Contacts
  • Dal.事件.产品
  • 达尔事件分类
  • .
  • Dal.Search.Contacts
  • Dal.Search.产品

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

这是好形式吗？

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

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

4

7 回答 7

5

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

"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

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

于 2009-02-25T21:56:34.873 回答
5

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

IE：

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

反而：

Org.MyCompany.Contacts

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

于 2009-02-25T22:46:58.060 回答
2

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

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

于 2009-02-25T19:54:30.080 回答
1

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

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

于 2009-02-25T22:02:29.913 回答
1

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

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

class Vehicle 

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

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

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

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

尽管它没有具体解决有关名称空间的问题，但我的直觉告诉我情况是相似的。我想说，如果你能避免这种情况，那么你应该这样做。

于 2009-02-25T22:40:18.733 回答
1

另请查看此 MSDN 文章以获取命名空间的指南

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

于 2011-01-07T08:47:55.243 回答
0

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

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

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

于 2009-02-25T22:13:53.257 回答