命名规范和命名空间

Question

命名规范和命名空间

4

如果我有一个图层上的对象和另一个图层上同名的对象，是在对象名称前加一些前缀还是新建命名空间并使用完全限定名称来引用它们更好？例如：

namespace Project1.Data
Object Person;

namespace Project1.Model
Object Person;

Data.Person.Name=Person.Name;

OR

dbPerson.Name= Person.Name;

- zsharp

5个回答

2

这取决于您在多大程度上引用重载的名称。

如果您在一个文件中使用它多次，请使用第一种方法。

如果您只使用一两次，则写出完全限定名称，以便其他人不必在文件顶部寻找以确定您正在引用哪个对象。

- RossFabricant

1

这真的取决于您请求它们的频率。通常，我使用缩写版本来引用我最常使用的类型，并使用较少使用的类型的完整名称。我会说，如果您最终在同一文件中有很多使用两者的情况，那么您应该使用命名空间别名，但对我而言，这只是在代码膨胀到难以跟踪时才采用的最后手段。

- Paul Sonier

1

我也有同样的想法。我认为更改类的名称是一个不好的主意。例如，我有一个数据访问层和一个业务层。两者都涉及用户。所以我有...

Project1.Business.User Project1.DataAccess.User

试图想出创新的类名是浪费时间，可能会导致没有意义的奇怪类名。给类命名已经够头疼的了。

我同意McWafflestix的观点：“我使用缩写版本来引用我最常用的类型，并为较少使用的类型使用更长的名称。”

- CountZero

1

很简单。听一下.NET框架的指导原则实际上是有帮助的（尽管书中的许多材料只是红蒙德仙境中的Java风格元素再次出现）。

您应该避免在跨项目/库混合命名空间中使用类似的类型名称，即在通用领域和模型中进行混合（即使在C++中也是如此，它非常严格和强大，但它也有编译器、解析和枚举样式的编译器崩溃和问题）。

因此，即使始终完全限定名称也不是绝对可靠的（顺便说一句，别名和“using”非常有限，并且最多会导致轻微的重复，同时证明了C#在泛型编程等方面的弱点）。

根据我的经验，数据域类型是更合适的名称的主要目标，因此需要进行名称重构，这是：

a）廉价的（作为富ASTs但简单的adt-s支持过程，例如在C#中，右键单击IDE并根据类型挑战动态Ruby粉丝/支持者感到强大）

[也可以理解为：4.0动态特性羊会责怪所有人，但不会考虑命名空间或函数式JS、带模板的C（而不是带类的C）或类似的东西]

b）更好地传达语义，即意图（即管道+支持构建自己的处理）

c) 通常是原始但有类型的性质或消息（不是面向对象的; 即OO风格批评，如上述书籍本身就打破了简介，将所有“模型”提升到参考领域）。

d) “别名”成为跨域使用中有用的工件（实际上可能且非常类似于2020..即值类型编程），

真的没有规则，但要注意，在开发中最不希望看到的是命名空间混合..这意味着对于一个受控制的开发人员来说只有一件事情：混淆。当然还有一些较少的、更多的编译时和IntelliNonsense错误..

在所有语言中都存在困难问题，因此这是您的设计/命名问题..甚至工具供应商也可以搞砸机器解析..例如基于过时浏览信息的增强流行IDE的输出；然而，其他人确实为受控语言做得很好。

并不是我反对重复名称，有些情况（它们很棘手，但是必要的）需要混合双重+互操作+表示等其他模型的情况，其中相同的名称使其更可读；即重复是双重使用的必要条件。但这是C#不友好或鼓励的较低级别习语（关于开销）。

- rama-jka toti

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

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

- M4N · Accepted Answer

我会使用命名空间和命名空间别名，例如：

在适当的命名空间中定义你的类：

namespace Project1.Data
{
    public class Person {...}
}
namespace Project1.Model
{
    public class Person {...}
}

在使用类时，要么使用完全限定名称，要么为命名空间定义别名（如果完整命名空间较长，则尤其有用）：

using data = Project1.Data;
using model = Project1.Model;

data.Person p1 = new data.Person();
model.Person p2 = new model.Person();
//...
p1.Name = p2.Name;