4

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

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

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

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

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

4

5 回答 5

4

微软显然赞成一些冗余。一个常见的例子是：

System.Xml.XmlDocument

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

于 2009-02-05T21:31:28.380 回答
2

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

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

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

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

于 2009-02-05T21:25:48.717 回答
2

第一篇在 StackOverFlow 上发帖，关于一个老问题。请对我好一点:)

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

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

例如： Xml.XmlDocument vs Html.HtmlDocument

与其导入 XML 和 HTML 命名空间，不如只包含包含的命名空间？它会变成这样：

Xml.Document 对比 Html.Document

于 2010-11-26T16:36:06.793 回答
1

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

于 2009-02-05T21:13:29.147 回答
0

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

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

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

于 2009-02-05T21:22:21.797 回答