我們目前正在重組我們的一些服務項目，因此它們的命名更合乎邏輯。我們有以下結構：命名空間 - 深度多深
Djp.Services。 類型。 服務名稱
這似乎是有道理的邏輯分組，但是我想知道的是什麼，是不是可以接受的基於項目的文件夾下，這個進一步的水平。例如，一個項目被稱爲
Djp.Services.Management.Data
在這個項目中，我們有一個「POCO」文件夾和「庫」文件夾中，這意味着，在主要對象，下這些文件夾將有一個5層深的命名空間。
命名空間的深度應該避免，還是完全合理？
遵循應用程序結構邏輯的任何命名空間都很好 - 無論長度如何。
謝謝，這就是我的感受。這只是我想澄清我的想法的那個時代。 – MrEdmundo 2010-10-08 11:50:23
我其實是在思考同樣的問題，這個問題/答案確實有助於理清它。 – 2012-05-14 19:06:02
東西聞起來太長了，退一步分析一下。如果它通過召集，那麼我完全同意@Bozho。
軟件開發是非常客觀的，充滿了強硬規則的例外。 （無法抗拒）
爲你的quip :) +1 – 2012-05-14 19:07:05
使您的文件夾結構與您的命名空間結構相匹配可能很方便，但使命名空間結構與文件夾結構匹配沒有任何意義。
命名空間的類型和成員是您正在製作的東西。這是你的工藝和你應該關心的事情的輸出。文件夾中的文件是幫助您做到這一點的一種方式。你可能已經構建了這些文件夾，以便它們匹配一個明智的名稱空間（實際上，當你這樣做時，「編寫」了名稱空間結構），在這種情況下，所有這些都是好的，但是你也可能沒有這樣做。名稱空間對於程序集的創建者和用戶都很重要，文件夾結構只針對創建者。
忽略深度，忽略文件夾，查看由名稱創建的空間。
我們有一個七層深的命名空間，在這個類的最後有一個第八個符號。 Visual Studio 2010左上角的下拉列表允許您在此文件中選擇類，它不適合我們的完全限定的類名稱，並且當您將鼠標懸停在其上時，沒有工具提示，因此找到類的唯一方法名稱是解除源視圖並將其在兩個監視器上展開。
我知道這是依賴於名稱的總長度，而不一定是嵌套的命名空間的數量，但我要繼續前進，並將其定義爲「太深」 :)
順便說一下，嘗試使用'namespace foo {使用bar;使用嘶嘶聲; class buzz {}}'而不是'使用bar;使用嘶嘶聲; namespace foo {class buzz {}}'。 – 2010-10-08 11:36:52
如果一個新開發者的眼睛開始瞥見只讀你的類名稱，它太深:)否則，讚美'使用'！ – shambulator 2010-10-08 11:38:30
@shambulator你命名理由。這並不能讓名稱空間的深層嵌套成爲一種好的做法，但它有點幫助。 – 2010-10-08 11:51:50