根据 .NET Framework 设计指南命名命名空间中的类型
我在为我们的新应用程序系列制定合理的类型命名方案时遇到一些问题。 我想遵循 .NET Framework 开发人员指南 - 开发类库的设计指南< /a>，但我开始怀疑这是否是一个好主意。
我想使用 Company.Product.Feature 命名空间方案作为基础。
问题 1：我们有自己的控件和表单基类，我希望将它们放入 Company.Product.Forms 命名空间中。 但是，根据指南，我们不应该让我们的类型名称为 Control 或 Form，即使它们在我们自己的 Company.Product.Forms< 中/code> 命名空间，因为它们会与系统类型冲突。
问题 2：我们的应用程序中有一些独特的功能区域，我希望这些区域能够进入它们自己的 Company.Product.Feature 命名空间。 许多这些功能具有相似的设计，具有控制器和一些视图，因此在每个 Company.Product.Feature 命名空间下，我希望有名为 Controller 的类型，SomeView、AnotherView 等。但是，根据指南，我们不应该在不同的命名空间中使用相同的类型名称。
我认为克服这些问题的唯一解决方案是在类型上添加前缀，从而在某种程度上使命名空间变得多余。 或不？
I'm having some problems to come up with a sane type naming scheme for our new line of applications. I want to follow the .NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries, but I'm starting to wonder if that's such a good idea.
I'd like to use the Company.Product.Feature namespace scheme as a basis.
Problem 1: We have our own control and form base classes, and I want these to go into the Company.Product.Forms namespace. However, according to the guidelines, we shouldn't let our type names be Control or Form, even if they are in our own Company.Product.Forms namespace, since they will clash with system types.
Problem 2: We have some distinct feature areas in the application and I want these to go into their own Company.Product.Feature namespace. Lots of these features have similar design, with a controller and some views, so under each Company.Product.Feature namespace I'd like to have types named Controller, SomeView, AnotherView, etc. However, according to the guidelines, we shouldn't have the same type names in different namespaces.
The only solution I see to overcome these problems is to prefix the types with something that in some way makes the namespaces redundant. Or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
微软显然倾向于一些冗余。 一个常见的例子是：
通用类名，即使绑定在正确的命名空间内，也会让许多喜欢避免完全限定其类实例化的程序员感到头疼。 “文档”可以是 Xml、Html 或 Word 文档。 如果您碰巧使用“Document”类导入多个命名空间，这种歧义将导致无尽的混乱。
Microsoft clearly favors some redundancy. A common example is:
General class names, even bound within a proper named namespace can cause headaches for the many programmers who like to avoid fully qualifying their class instantiations. "Document" could be an Xml, Html or word document. This ambiguity will cause endless confusion if you happen to import more than one namespace with a "Document" class.
出于某种原因，我更喜欢 Company.Product.UI。 我也会在网络上使用这个命名。
关于问题 1，如果这些是基类型，则可以在类名中包含 Base。
然后，您通常拥有一组特定于域的控件，它们不会与内置类型发生冲突。
如果您还保留常见 UI 控件（TextBox、DropDownList 等）的包装，那么我实际上建议为它们使用前缀，
也许这个前缀是产品的缩写名称。
然后，如果你这样做，那么你可能希望保持一致，并对所有类型都这样做，
不管它们是否是有歧义的名字。
我以我自己的经历告诉你。
您最终将不断地将鼠标悬停在变量上以查看它们的完整类型名称等，您将使用别名等。
代码会更难阅读。
问题2：在GUI层，我倾向于打破这些规则，因为你需要命名一致性（常见动词；显示、编辑、列表）。 如果指南另有说明，我相信这是因为它不够具体。
I'd prefer Company.Product.UI, for some reason. I would use that naming for the web, too.
Regarding problem 1, if these are base types, you might include Base in the class name.
Then, you typically have a set of domain specific controls, which won't clash with built-in types.
If you also keep wrappers for common UI controls(TextBox, DropDownList etc), then i would actually recommend use a prefix for them,
maybe this prefix is an abbreviated name of the product.
And then, if you do that, then you might want to be consistent, and do it for all types,
regardless of whether they are ambigious names or not.
I tell you from my own experience.
You'll end up constantly hovering over variables to see their full type names, etc, you will use aliasing etc..
The code will be harder to read.
Problem 2: While at GUI layer, i tend to break these rules, because you will want naming consistency(common verbs; Show,Edit,List). If the guideline tells you otherwise, i would believe it is because it is simply not specific enough.
StackOverFlow 上的第一篇文章，关于一个老问题。 请善待我:)
微软有时可能会支持一些冗余，但情况并非总是如此。
至于 Document 与 XMLDocument 的问题，当您知道可能有不止一种类型的文档时，为什么不在声明中包含命名空间的限定部分呢？
例如 ：
Xml.XmlDocument与
Html.HtmlDocument为什么不只包含包含的命名空间，而不是导入 XML 和 HTML 命名空间？ 它会变成这样：
Xml.Document与
Html.DocumentFirst post here in StackOverFlow, on an old question. Please, be kind with me :)
Microsoft MIGHT sometimes favor some redundency but it's not always de case.
As for the Document vs XMLDocument problematic, when you know there might be more than one type of document, why not just include the qualifying part of the namespace in the declaration?
For example :
Xml.XmlDocumentvs
Html.HtmlDocumentInstead of importing the XML and HTML namespace, why not just include the containing namespace? It would become like this :
Xml.Documentvs
Html.Document如果它符合逻辑，那就去做吧。 它们只是指导方针，而不是法律。 （并不是说你也不能打破它。）
If it makes logical sense, then do it. They are just guidelines, not the LAW. (not that you cant break that too.)
在不同的命名空间中使用相同名称的类是违反准则的，这使得阅读代码变得有点困难，因为当你看到“Controller”时，你必须在心里将其映射到“Feature1.Controller”或“Feature2.Controller”。
我更愿意使用 Company.Product.Features.Feature1.Feature1Conroller 和冗余信息，或者使用 Company.Product.Features.Feature1Controller 如果它打扰你（我个人不喜欢有太多的命名空间）。
但请随意违反准则，规则可以让您在违反之前进行思考:-)
Having classes in the with the same name in different namespaces is just is against the guidelines for a reason, it makes reading the code just a little bit harder because when you see "Controller" you have to mentally map it to "Feature1.Controller" or "Feature2.Controller".
I would prefer to use Company.Product.Features.Feature1.Feature1Conroller with the redundant information or maybe Company.Product.Features.Feature1Controller if it bothers you (and I personally don't like having too many namespaces).
But feel free to break the guidelines, rules are there to make you think before you break them :-)