我是否應該擔心命名空間號/長度/范圍的統治？

Question

我最近將正在進行的解決方案從24個項目重組為4個。

為了保持在“主”項目中組織豐富的文件，事物在文件夾中的文件夾中。 我認為我保留了解決方案內容的邏輯，可發現的安排。

因此，當然，我最終得到了像AppName.DataAccess.NHibernate.Fluent.Mappings這樣的名稱空間。

當我的項目有一個有點深層嵌套的文件夾結構時，是否有任何令人信服的理由我應該關心命名空間層次結構？

（我不擔心解決或管理 using 指令;我讓ReSharper在這里做所有繁重的工作。）

Answer 1

我只會在有明顯維護優勢的地方展平。

命名空間更多用於組織目的，還有助於減少命名沖突。 我傾向於使我的命名空間與.NET Framework和其他主要庫命名空間保持一致。 這有助於其他人更容易地找到課程。 （正如你所說，可發現的安排。）例如，我的路徑實用程序在Missico.IO.Path下，我的數據訪問庫在Missico.Data下，我的應用程序在AppName.DataManager下的數據訪問（使用Missico.Data和所有其他數據）命名空間）。

我總是在根命名空間使用我的姓氏或公司名稱。 （任何名詞都可以。）這允許用戶（程序員）通過源代碼中的簡單名稱更改或庫引用的使用別名輕松解決命名沖突。

using Company = Missico;
String x = Company.IO.Path.CommonPath("", "");

我嘗試為每個命名空間保留一個文件夾。 如果命名空間是嵌套的，則嵌套文件夾。 這有助於我和其他人更快地找到源代碼，因為他們熟悉命名空間結構。 為什么要讓他們學習兩種結構。 每個文件夾都包含該命名空間的所有源文件，復雜類除外。 他們得到了自己的子文件夾（不更改名稱空間。）我最終可能會得到一個名稱空間文件夾，其中包含四個或五個子文件夾，用於復雜類和支持類。

請注意，由於定義System命名空間會導致各種麻煩，因此我使用Core作為我的“系統/全局”命名空間。

Answer 2

我始終認為可以在有意義的命名空間名稱中保留小的可重用類。 所以我的答案是否定的，不要試圖縮小命名空間層次結構。