我的背景主要是作爲Java開發人員，但最近我一直在.NET中做一些工作。所以我一直試圖在家裏做一些簡單的項目，以更好地使用.NET。我已經能夠將我的大部分Java經驗轉移到.NET（特別是C＃）中，但唯一讓我感到困惑的是名稱空間。.NET命名空間
我知道命名空間與Java軟件包相似，但是從我所知道的主要區別在於，對於Java軟件包，它們使用實際的文件夾來顯示分隔，而在.NET中並不存在所有文件在一個文件夾中，並且在每個類中只聲明名稱空間。
我覺得這很奇怪，因爲我總是看到軟件包是一種組織和分組相關代碼的方式，使得它更易於瀏覽和理解。因爲在.NET中，這種方式不適用於這種工作，加班，項目顯得更加擁擠並且不容易導航。
我在這裏錯過了什麼嗎？我必須。我應該在解決方案中將事情分解成單獨的項目嗎？還是有更好的方法來保持項目中組織的類和文件？
編輯：正如布萊爾指出，這是幾乎相同的問題here問。
我不能說這是一個最佳實踐，但我經常看到文件組織在一個目錄層次結構中，該目錄層次結構反映了命名空間。如果它更適合你的代碼的心智模型，那就這麼做 - 我想不出有什麼傷害。僅僅因爲.NET模型不強制名稱空間，項目和目錄結構之間的關係並不意味着如果你願意，你不能擁有這樣的關係。
如果你需要管理多個程序集，這可能會減慢編譯速度並增加一點開銷，所以我會對將代碼分解爲比你需要的更多項目有點謹慎。
編輯：請注意，這個問題是近的should the folders in a solution match the namespace?
重複您可以將文件夾添加到您的每個命名空間的解決方案。雖然它仍然會編譯爲單個可執行文件，但它會組織源文件並提供（我認爲的）所需的效果？
我通常添加一個文件夾在我的項目每個命名空間，其嵌套根據同一層次（MyApp.View.Dialogs例如）
一個VS解決方案通常包含一個或多個項目。這些項目有默認的命名空間（通常命名空間只是項目的名稱）。通常情況下，如果你的項目中添加一個文件夾，在它所有的類將被命名如下：
DefaultNamespace.FolderName.ClassName
當然，你可以改變項目的默認命名空間，並且以任何你想要的方式命名你的類。
至於何時/如何將東西分解爲項目，這是一個經驗和/或偏好問題。但是，爲了保持項目的組織性，您絕對應該在解決方案中將項目分解成項目。如果管理太多組件變得麻煩（正如布萊爾建議的那樣），您可以將您的組件集中到一個組件中。ILMerge最棒的地方在於，即使最終只有一個程序集，您的所有類仍保留其原始的完全限定名稱。
記住VS解決方案對代碼沒有影響也很重要，他們沒有建立。 VS解決方案不過是組合項目的一種方式;它是構建並轉化爲DLL的項目。
最後，VS讓我們在解決方案的任何位置添加「虛擬」文件夾。這些文件夾不會映射到文件系統中的文件夾，而只是用作幫助您在解決方案中組織項目和其他工件的另一種手段。
是的，在.NET命名空間不依賴於文件系統或其他任何東西。我認爲這是一個很大的優勢。例如，您可以將代碼拆分到允許靈活分發的不同程序集中。
在Visual Studio中工作時，當您將新文件夾添加到項目樹時，IDE傾向於引入新的名稱空間。
下面是從MSDN一個有用的鏈接：
命名的命名空間 的一般規則是使用公司名稱，後跟 技術名稱和可選的 功能和設計如下。
CompanyName.TechnologyName [.Feature] [設計]
當然你也可以在你找到更適合的方式使用的命名空間。但是，如果你要分享你的代碼，我會建議遵循公認的標準。
編輯：
我強烈推薦任何.NET開發人員獲得的Framework design guidelines副本這本書將幫助您瞭解如何和爲什麼.NET設計。
CompnayName.Technology向您購買什麼？以這種方式命名事物我看不出任何好處。任何見解？ – 2008-09-11 04:17:50
您是否閱讀過MSDN文章？事實上，當第二方第三方程序集使用相同的根名稱空間時，我有這種情況。 – aku 2008-09-11 07:41:11
命名空間純粹是語義。雖然他們通常會反映文件夾結構，但至少在使用Visual Studio IDE時，他們不需要。
您可以在多個庫中引用相同的命名空間，但很正確。
事實上，.Net環境允許您將代碼扔在像牆上的意大利麪條一樣的IDE /文件系統中。
但這並不意味着這種方法是理智的。通常堅持前面提到的project.foldername.Class方法是一個好主意。將一個命名空間的所有類保存到同一個類中也是一個非常好的主意。在Java中，你可以做這樣的事情以及獲得所有你想要的「靈活性」，但是這些工具往往強烈地阻止它。說實話，我被介紹給.Net世界的最令人困惑的事情之一就是，由於相對較差的指導，這可能是多麼渺茫/不一致。儘管如此，很容易用一點想法來組織事情。:)
我一直認爲源文件組織和分配標識符類和對象是兩個不同的問題。我傾向於將相關類保存爲組，但不是每個組都應該是一個名稱空間。名稱空間存在（或多或少）來解決名稱衝突的問題 - 在像C這樣的扁平名稱空間語言中，如果不跳過像mycompany_getcurrentdate或MYCGetCurrentDate這樣的標識符，就無法走兩步，因爲存在與另一個函數衝突的風險第三方（或系統）庫是那麼小。如果你爲每個邏輯分隔創建了一個包或者名字空間，你會得到（Java示例）類名，例如java.lang.primitivewrapper.numeric.Integer，這太過於誇張了。
命名空間是一個邏輯分組，而項目是一個物理分組。
爲什麼這很重要？想想.NET 2.0,3.0和3.5。 .NET 3.0基本上是帶有一些額外程序集的.NET 2.0，3.5又增加了一些程序集。例如，.NET 3.5添加了DataPager控件，這是一個Web控件，應該分組在System.Web.UI.WebControls中。如果命名空間和物理位置完全相同，則不可能是因爲它位於不同的程序集中。
因此，有命名空間作爲獨立的邏輯實體，意味着你可以擁有這都是邏輯組合在一起，因爲他們註定相互結合使用幾個不同的組件成員。
（此外，還有沒有錯，有相當類似的物理和邏輯佈局。）
不同的是，.NET命名空間有沒有什麼做用java包。
.NET命名空間是純粹的管理範圍的聲明，並沒有什麼做的文件，項目或它們的位置。
它是在一個特定的命名空間中聲明非常簡單的一切，當你 包含「使用」該命名空間訪問。
很容易。
名稱，以及是否/如何多的選擇「」你使用的分離器完全取決於你。
VS默認添加.foldernames到您的命名空間只是嘗試是有益的。
本文介紹了命名空間相當不錯： http://www.blackwasp.co.uk/Namespaces.aspx
它也有一個例子命名朝端約定，雖然你的名字約定是您的來電！ ;）
說，我工作過的大多數地方和我一起工作過的人都從公司名稱開始，這是明智的，因爲它使該公司的typenames與衆不同，（與其他，庫，供應商，開源projcts等）
對不起，但我保證我做了搜索之前，我問，只是顯然不是正確的事情。 – 2008-09-11 02:48:47