我正在为CRUD业务应用程序创建一个类库。业务对象（具有相关数据访问层对象）的主要“类别”是：
截至目前，我的命名空间设置如下：
请注意，每个班级都以相同的名称结尾。
这是好形式吗？
此命名空间约定是否会出现任何问题？对于查看/使用此代码的其他人可能有什么困惑吗？
我确实意识到在表单代码中，一个缺点是我必须使用命名空间限定所有对象。对我来说，这不是什么大问题。如果这是一个词，我通常更喜欢一点显而易见。
答案 0 :(得分：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
这个人为的例子可能会成为一个问题。
答案 1 :(得分：5)
在实施任何特定模式之后，通常不建议您的软件包，而是它们所属的业务或功能域。
即：
Org.MyCompany.BusinessObjects.Maintenance.Contacts
Org.MyCompany.BusinessObjects.Incidents.Contacts
Org.MyCompany.BusinessObjects.Search.Contacts
代替：
Org.MyCompany.Contacts
将包含类/接口/对象/在“联系人”上执行操作的任何内容。
答案 2 :(得分：2)
我认为该项目将受益于一些缩写。当我在过去遇到这样的问题时，我通常会用一些文档来解释一些用作命名空间的缩写。我通常将这些缩短的名称限制为3-5个字符。这不仅增加了表单代码中的一般代码可读性，而且我还发现较短的名称可以减少与其他编码人员的混淆。
我希望有所帮助。在一天结束时，它实际上取决于您团队的偏好......
答案 3 :(得分：1)
在经历了这么多之后，我们尝试保持命名空间的数量较少（对于一个非常大的项目少于几打），并且命名空间的深度很短（小于5左右）。从消费的角度来看（开发人员使用我们的代码库），这是一个开销，只需要跟踪大量具有少量类的命名空间就没有什么好处。
我们也根据使用情况进行分组。如果开发人员很可能总是将某些类与其他类一起使用，即使（在您的示例中）一个可能与维护相关而另一个不相关，如果它们在逻辑上，操作上或程序上相关，我们将它们放在相同的命名空间中。单独的功能（例如，特定于维护的逻辑）使用提供者模型分解为另一个命名空间。由于开发人员不太可能需要修改包含提供程序的功能，因此需要更深入，独立的命名空间。
答案 4 :(得分：1)
您的命名空间层次结构看起来类似于称为嵌套泛化的条件。这是当你有一些派生出多种不同方式的课程时。
想象一下类层次结构如下：
class Vehicle
class Car : Vehicle
class CarRed : Car
class CarBlue : Car
class Truck : Vehicle
class TruckRed : Truck
class TruckBlue : Truck
请注意，车辆可以是汽车或卡车。此外，车辆可以是红色或蓝色。这非常有效，但是当您想要添加新颜色或车辆类型时会出现问题，因为修改的负担会以二次方式增长。
这个问题由GOF设计模式书描述 - 特别是桥模式。
虽然它没有专门解决关于命名空间的问题，但我的直觉告诉我情况类似。我会说，如果你可以避免这种情况，那么你应该这样做。
答案 5 :(得分：1)
另请参阅此MSDN文章，了解命名命名空间的指南
命名空间的名称： http://msdn.microsoft.com/en-us/library/ms229026.aspx
答案 6 :(得分：0)
每个库使用一个命名空间，每个可执行源代码集使用一个命名空间。名字总是很短。例如，在我目前正在处理的可执行文件中，我有：
这看起来效果很好。我发现应该避免非常复杂的命名空间方案，就像非常复杂，深层次的层次结构应该这样。