如果我在一个层上有与另一层上的对象同名的对象，最好用一些前缀更改对象名称还是使用新的命名空间并使用完全限定的名称来引用它们？例如：
namespace Project1.Data
Object Person;
namespace Project1.Model
Object Person;
Data.Person.Name=Person.Name;
OR
dbPerson.Name= Person.Name;
【问题讨论】：
标签： c# naming-conventions
我会使用命名空间和命名空间别名，例如：
在适当的命名空间中定义你的类：
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;
【讨论】：
这取决于您提及重载名称的频率。
如果您在一个文件中多次使用它，则使用第一种方式。
如果您只使用一次或两次，请写出完全限定名称，这样其他人就不必在您的文件顶部四处寻找您所指的对象。
【讨论】：
这实际上取决于您请求每个人的频率。一般来说，我对我最常提到的类型使用缩短的版本，对不常用的类型使用较长的名称。我最终会说，如果你最终在同一个文件中有很多用法，你应该使用命名空间别名，但对我来说，这是最后的手段，只有在代码膨胀到难以处理的地步之后关注正在发生的事情。
【讨论】：
我自己也有同样的想法。我认为更改课程的名称是一个坏主意。例如，我有一个数据访问层和一个业务层。两者都与用户打交道。所以我有...
Project1.Business.User Project1.DataAccess.User
尝试为类想出有创意的新名称是浪费时间，并且可能意味着对没有什么意义的类的奇怪名称。命名类已经够让人头疼的了。
我同意 McWafflestix 的观点，“我对我最常提及的类型使用缩短的版本，对不常用的类型使用较长的名称”。
【讨论】：
这很简单。听一遍 .NET 框架指南实际上会有所帮助（尽管书中的大量材料只是简单的 Java 风格元素，但在 Redmond Wonderland 中再次出现）..
您应该避免在交叉或项目内/库混合命名空间中使用类似的类型名称，即。一般跨域和模型混合（即使是在极其严格和强大的 C++ 中，它也有编译器、解析和枚举式编译器崩溃和问题的化身）。
因此，即使始终完全限定也不是万无一失的（顺便说一句，别名和“使用”极为有限，充其量只会造成轻微的重复，并证明 C# 在泛型编程等方面的弱点）。
根据我的经验，数据域类型是更合适的名称的主要目标，因此对于名称重构来说：
a) 便宜（作为丰富的 AST 中的一个过程，但像在 C# 中一样简单的 adt-s 支持，在 IDE 中右键单击并根据类型挑战的动态 Ruby 粉丝/支持者感觉强大）
[也可以理解为：4.0 动态特性羊会责怪所有人，但不要考虑命名空间或函数式 JS、C-with 模板（不是 C-with-classes）或类似内容]
b) 更好地传达语义，即。意图（即管道+支持构建您自己的处理）
c) 通常具有原始但类型化的性质或信息（类型化而不是 OO；即前面提到的书中的 OO 风格的批评，它本身直接脱离了介绍，将所有“模型”提升到参考土地）
d) 并且“aliasing”成为跨域使用中的有用工件（这实际上是可能的，并且非常类似于 2020 年......即值类型编程）
确实没有规则，但请注意，您会在最意想不到的情况下在开发中看到名称空间的混合。这对于有管理意识的开发人员来说只意味着一件事：混乱。再加上不那么严重，当然还有更多的编译时间和 IntelliNonsense 错误..
所有语言的难题，所以这是您的设计/命名问题。。即使是工具供应商也可能搞砸机器来解析。说基于过时浏览信息的增强流行 IDE 的输出；再说一次，其他人在托管语言方面做得很好。
并不是说我反对重复名称，当混合双重 + 互操作 + 表示等其他模型时，有些情况（它们很难但必要）相同的名称使其更具可读性； IE。其中重复是双重使用的必要条件.. 但这是 C# 不友好或不鼓励使用的较低级别的习语（re: 赞成开销）。
【讨论】：