根据 .NET Framework 设计指南命名命名空间中的类型答案

【问题标题】：Naming types in a namespace by the .NET Framework Design Guidelines根据 .NET Framework 设计指南命名命名空间中的类型
【发布时间】：2009-02-05 21:09:32
【问题描述】：

我在为我们的新应用程序线提出一个合理的类型命名方案时遇到了一些问题。我想关注.NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries，但我开始怀疑这是否是个好主意。

我想使用 Company.Product.Feature 命名空间方案作为基础。

问题 1：我们有自己的控件和表单基类，我希望这些进入Company.Product.Forms 命名空间。但是，根据指南，我们不应该让我们的类型名称为 Control 或 Form，即使它们在我们自己的 Company.Product.Forms 命名空间中，因为它们会与系统类型发生冲突。

问题 2： 我们在应用程序中有一些不同的功能区域，我希望这些区域进入它们自己的 Company.Product.Feature 命名空间。许多这些功能具有相似的设计，带有控制器和一些视图，因此在每个 Company.Product.Feature 命名空间下，我希望有名为 Controller、SomeView、AnotherView 等的类型。但是，根据指南，我们不应该在不同的命名空间中有相同的类型名称。

我认为克服这些问题的唯一解决方案是在类型前面加上一些在某种程度上使命名空间变得多余的东西。还是不行？

【问题讨论】：

标签： c# naming-conventions namespaces naming

【解决方案1】：

微软显然倾向于一些冗余。一个常见的例子是：

System.Xml.XmlDocument

通用类名，即使绑定在一个正确命名的命名空间中，也会让许多喜欢避免完全限定其类实例化的程序员感到头疼。 “文档”可以是 Xml、Html 或 word 文档。如果您碰巧导入了多个具有“文档”类的命名空间，这种歧义将导致无穷无尽的混乱。

【讨论】：

我仍然不喜欢他们这样做的事实。我宁愿使用Xml.Document 和SomethingElse.Document，也不愿用它来污染我的命名约定。此外，你总是可以using XmlDocument = System.Xml.XmlDocument;
我同意它违背了命名空间的许多目的，但是微软使用了一些我不喜欢的约定。然而，偏离他们的标准可能会让你感到困惑（特别是如果你正在编写库类型的代码并且 .NET 的 api 和你的 api 之间的界限很模糊）

【解决方案2】：

出于某种原因，我更喜欢 Company.Product.UI。我也会为网络使用这个命名。

关于问题1，如果这些是基本类型，你可以在类名中包含Base。然后，您通常拥有一组特定于域的控件，它们不会与内置类型发生冲突。如果您还保留常见 UI 控件（TextBox、DropDownList 等）的包装器，那么我实际上建议为它们使用前缀，也许这个前缀是产品的缩写名称。然后，如果你这样做，那么你可能想要保持一致，并且对所有类型都这样做，不管它们是否是模棱两可的名字。

我以我自己的经验告诉你。您最终会不断地将鼠标悬停在变量上以查看它们的完整类型名称等，您将使用别名等。代码将更难阅读。

问题 2：在 GUI 层，我倾向于打破这些规则，因为您需要命名一致性（常用动词；显示、编辑、列表）。如果指南告诉你不是这样，我相信那是因为它不够具体。

【讨论】：

【解决方案3】：

StackOverFlow 上的第一篇文章，关于一个老问题。请对我好一点:)

通用类名，即使绑定在一个正确命名的命名空间中，也会让许多喜欢避免完全限定其类实例化的程序员感到头疼。 “文档”可以是 Xml、Html 或 word 文档。如果您碰巧导入了多个具有“文档”类的命名空间，这种歧义将导致无穷无尽的混乱。

Microsoft 有时可能会支持一些冗余，但并非总是如此。至于 Document vs XMLDocument 的问题，当您知道可能存在不止一种类型的文档时，为什么不在声明中包含命名空间的限定部分？

例如： Xml.XmlDocument 对比 Html.HtmlDocument

除了导入 XML 和 HTML 命名空间，为什么不只包含包含命名空间呢？会变成这样：

Xml.Document 对比 Html.Document

【讨论】：

【解决方案4】：

如果合乎逻辑，那就去做。它们只是指导方针，而不是法律。（并不是说你也不能打破它。）

【讨论】：

【解决方案5】：

在不同的命名空间中具有相同名称的类是违反指南的原因，它使阅读代码有点困难，因为当你看到“控制器”时，你必须在心理上将它映射到“Feature1” .Controller”或“Feature2.Controller”。

我更愿意将 Company.Product.Features.Feature1.Feature1Conroller 与冗余信息一起使用，或者如果它打扰您，我可能会使用 Company.Product.Features.Feature1Controller（我个人不喜欢有太多的命名空间）。

但请随意违反准则，规则可以让您在违反规则之前思考 :-)

【讨论】：