.NET框架設計指南在名稱空間中命名類型

Question

我有一些問題需要爲我們新的應用程序系列提供一個理智的類型命名方案。我想要遵循.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等。但是，根據指導原則，我們不應該有相同的在不同的命名空間中鍵入名稱。

我看到克服這些問題的唯一解決方案是在類型前面添加一些以某種方式使命名空間變得冗餘的東西。或不？

Answer 1

微軟顯然贊成一些冗餘。一個常見的例子是：

System.Xml.XmlDocument 

一般類名，一個名爲正確命名空間內甚至勢必會引起頭痛誰喜歡，以避免完全限定的類實例的很多程序員。 「文檔」可以是Xml，Html或Word文檔。如果您碰巧用一個「Document」類導入多個名稱空間，這種歧義將導致無窮無盡的混淆。

Answer 2

如果它是合乎邏輯的，那就去做吧。他們只是指導方針，而不是法律。 （不是你不能打破這個）

Answer 3

在不同名稱空間中使用相同名稱的類只是違反了原因的指導原則，它使得閱讀代碼變得更加困難，因爲當你看到「控制器「，你必須精神上映射到」Feature1.Controller「或」Feature2.Controller「。

我寧願使用具有冗餘信息的Company.Product.Features.Feature1.Feature1Conroller，或者如果它困擾你（我個人不喜歡有太多命名空間），可能使用Company.Product.Features.Feature1Controller。

但隨時打破準則，規則在那裏讓你打破他們:-)

Answer 4

我寧願Company.Product.UI，由於某種原因，之前你的想法。我也會使用網絡命名。

關於問題1，如果這些是基本類型，那麼可以在類名中包含Base。 然後，您通常會擁有一組特定於域的控件，這些控件不會與內置類型衝突。 如果您還保留常用UI控件（TextBox，DropDownList等）的包裝，那麼我實際上建議爲它們使用前綴， 也許這個前綴是產品的縮寫名稱。 然後，如果你這樣做，那麼你可能想要保持一致，並且對於所有類型， 都這樣做，不管它們是否是有名的名稱。

我從我自己的經驗告訴你。 你最終將不斷懸停在變量上以查看完整類型名稱等，您將使用別名等。 代碼將更難以閱讀。

問題2：在GUI層時，我傾向於打破這些規則，因爲您需要命名一致性（常見動詞;顯示，編輯，列表）。如果指南告訴你，否則，我會相信這是因爲它不夠具體。

Answer 5

第一篇文章在StackOverFlow中的舊問題。請跟我是那種:)

一般類名，一個名爲正確命名空間內甚至勢必會引起頭痛誰喜歡，以避免完全限定的類實例的很多程序員。 「文檔」可以是Xml，Html或Word文檔。如果您碰巧用一個「Document」類導入多個名稱空間，這種歧義將導致無窮無盡的混淆。

微軟可能有時候會偏袒某​​些redundency，但並非總是如此。 至於Document vs XMLDocument有問題，當你知道可能有多種類型的文檔時，爲什麼不在聲明中包含名稱空間的合格部分呢？

例如： Xml.XmlDocument VS Html.HtmlDocument

而不是導入XML和HTML命名空間，爲什麼不包括含命名空間？它會變成這個樣子：

Xml.Document VS Html.Document