4

私たちの新しい一連のアプリケーションに適したタイプの命名スキームを考え出すのにいくつか問題があります。.NET Framework Developer's Guide - Design Guidelines for Developing Class Librariesに従いたいと思っていますが、それでいいのか疑問に思っています。

Company.Product.Feature名前空間スキームをベースとして使用したいと思います。

問題 1:独自のコントロールとフォームの基本クラスがあり、これらをCompany.Product.Forms名前空間に入れたい。Controlただし、ガイドラインによると、システム型と競合するため、型名をorにするべきではありませんForm。たとえそれらが独自のCompany.Product.Forms名前空間にあるとしてもです。

問題 2:アプリケーションにはいくつかの異なる機能領域があり、これらを独自のCompany.Product.Feature名前空間に入れたいと考えています。これらの機能の多くは、コントローラーといくつかのビューを備えた同様の設計を持っているため、各名前空間の下に、、 などのCompany.Product.Feature名前を付けたいと思います。名前空間。ControllerSomeViewAnotherView

これらの問題を克服するために私が考える唯一の解決策は、何らかの形で名前空間を冗長にする何かを型にプレフィックスすることです。か否か？

4

5 に答える 5

4

Microsoft は明らかに冗長性を優先しています。一般的な例は次のとおりです。

System.Xml.XmlDocument

一般的なクラス名は、適切な名前の名前空間内にバインドされていても、クラスのインスタンス化を完全に修飾することを避けたい多くのプログラマーにとって頭痛の種になる可能性があります。「ドキュメント」は、Xml、Html、またはワード ドキュメントです。「ドキュメント」クラスで複数の名前空間をインポートした場合、このあいまいさにより無限の混乱が生じます。

于 2009-02-05T21:31:28.380 に答える
2

古い質問について、StackOverFlow に最初に投稿します。どうか、私に親切にしてください:)

一般的なクラス名は、適切な名前の名前空間内にバインドされていても、クラスのインスタンス化を完全に修飾することを避けたい多くのプログラマーにとって頭痛の種になる可能性があります。「ドキュメント」は、Xml、Html、またはワード ドキュメントです。「ドキュメント」クラスで複数の名前空間をインポートした場合、このあいまいさにより無限の混乱が生じます。

Microsoft は、冗長性を支持する場合もありますが、常にそうであるとは限りません。Document と XMLDocument の問題に関しては、複数のタイプのドキュメントが存在する可能性があることがわかっている場合、名前空間の修飾部分を宣言に含めないのはなぜでしょうか?

例: Xml.XmlDocument vs Html.HtmlDocument

XML と HTML の名前空間をインポートする代わりに、それを含む名前空間をインクルードしてみませんか? 次のようになります。

Xml.Document 対 Html.Document

于 2010-11-26T16:36:06.793 に答える
2

何らかの理由で、Company.Product.UI を使用したいと思います。そのネーミングをウェブにも使用します。

問題 1 については、これらが基底型の場合、クラス名に Base を含めることができます。次に、通常、組み込み型と競合しない一連のドメイン固有のコントロールがあります。一般的な UI コントロール (TextBox、DropDownList など) のラッパーも保持している場合は、実際にはプレフィックスを使用することをお勧めします。おそらく、このプレフィックスは製品の省略名です。そして、それを行う場合、あいまいな名前であるかどうかに関係なく、一貫性を保ち、すべての型に対して行う必要があります。

私自身の経験からお伝えします。完全な型名などを確認するために常に変数の上にマウスを移動することになり、エイリアシングなどを使用することになります。コードは読みにくくなります。

問題 2: GUI レイヤーでは、命名の一貫性 (一般的な動詞; 表示、編集、リスト) が必要になるため、これらの規則を破る傾向があります。ガイドラインがそうでないと言うなら、それは単に十分に具体的ではないからだと思います.

于 2009-02-05T21:25:48.717 に答える
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 に答える