命名约定和命名空间

Question

如果我在一层上有与另一层上的对象同名的对象，那么最好是使用某些前缀更改对象名称，还是使用新的命名空间并使用完全限定名称引用它们？ 例如：

namespace Project1.Data
Object Person;

namespace Project1.Model
Object Person;

---

Data.Person.Name=Person.Name;

OR

dbPerson.Name= Person.Name;

Answer 1

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

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

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;

Answer 2

这取决于您引用重载名称的频率。

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

如果您只使用它一次或两次，则写出完全限定的名称，这样其他人就不必在文件顶部寻找您所引用的对象。

Answer 3

这实际上取决于您请求每个请求的频率。 一般来说，我对最常引用的类型使用缩写版本，对不太常用的类型使用较长的名称。 我最终会说，如果您最终在同一个文件中大量使用两者，那么您应该使用名称空间别名，但对我来说，只有在代码膨胀到难以使用的程度之后，这才是最后的手段关注正在发生的事情。

Answer 4

我自己也有同样的想法。 我认为更改类的名称是一个坏主意。 例如，我有一个数据访问层和一个业务层。 两者都与用户打交道。 所以我有...

Project1.Business.User
Project1.DataAccess.User

试图为这些类想出有创意的新名称是浪费时间，而且对于没有什么意义的类来说可能意味着奇怪的名称。 命名类已经够让人头疼的了。

我同意 McWafflestix 的观点：“我对最常引用的类型使用缩写版本，对不太常用的类型使用较长的名称”。

Answer 5

这很简单。 听听一次 .NET 框架指南实际上会有所帮助（尽管书中的大量材料只是简单的 Java 风格的 Elements Yet Again in Redmond Wonderland）。

您应该避免在跨项目/库内混合命名空间中使用类似的类型名称IE。 一般来说，跨领域和模型的混合（即使在极其严格和强大的 C++ 中，它也体现在编译器、解析和枚举式编译器崩溃和问题中）。

因此，即使始终完全限定也不是万无一失的（顺便说一句，别名和“使用”极其有限，充其量会导致轻微的重复，并证明 C# 在泛型编程等方面的弱点）。

根据我的经验，数据域类型是更合适名称的主要目标，因此对于名称重构来说，这是：

a）便宜（作为丰富 AST 中的过程，但像 C# 中那样简单的 adt-s 支持，在 IDE 中右键单击并根据类型挑战的动态 Ruby 粉丝/支持者感到强大）

[也可以理解为：4.0 动态功能羊会责怪每个人，但不会考虑名称空间或函数式 JS、带模板的 C（而不是带类的 C）、或类似]

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

c）通常具有原始但类型化的性质或消息（类型化不是面向对象；即前面提到的书中的面向对象风格的批评，它本身直接脱离了介绍，提升了所有“模型” ' 来引用土地）

d）和'别名'成为跨域使用中的有用工件（这实际上是可能的，并且非常像 2020 年......即值类型编程）

确实没有规则，但请注意，您会看到在最意想不到的情况下在开发中混合命名空间......这对于有管理意识的开发人员来说只意味着一件事：混乱。 当然，还有一些不那么严重的、更多的编译时错误和 IntelliNonsense 错误。

所有语言中都是棘手的问题，所以这是你的设计/命名问题。即使是工具供应商也可能会搞砸机器解析。比如增强型流行 IDE 的输出基于过时的浏览信息； 话又说回来，其他人在托管语言方面做得非常好。

并不是说我反对重复名称，在某些情况下（它们很困难但必要），当混合双重+互操作+表示等其他模型时，相同的名称使其更具可读性； IE。 其中重复是双重使用的必要条件。但这是 C# 不友好或不鼓励的较低级别习惯用法（回复：支持开销）。