這是根據目錄名命名命名空間的好實踐

我有一個目錄結構來存儲源文件。這是根據目錄結構命名空間的好習慣嗎？這是根據目錄名命名命名空間的好實踐

像

Models\model.cs 
Data\data.cs

一個是在命名空間模型中定義一個是在命名空間中的數據定義

來源

2011-02-18 user496949

是的，這是典型的方法，它也是一個由ReSharper等工具支持的方法。

這和Java方法之間的區別在於，您不需要從頂部向下添加目錄 - 只需從項目的默認命名空間即可。例如，假設我們創建了Foo.Bar.Baz.Model和Foo.Bar.Baz。數據方面，C＃和Java的解決方案可能是：

C＃：

Foo.Bar.Baz 
    Foo.Bar.Baz.csproj defining a project with default namespace of Foo.Bar.Baz 
    Model\ 
     SomeModel.cs 
    Data\ 
     SomeData.cs

的Java：

src\ 
    foo\ 
     bar\ 
      baz\ 
       model\ 
         SomeModel.java 
       data\ 
        SomeData.java

來源

2011-02-18 07:19:55

默認名稱空間設置是否意味着編譯程序集中的任何內容，或僅在項目中（以及新創建的文件，如果不更改它們）？ – 2011-02-18 07:40:21

肯定是慣例，但你也把項目名稱目錄名稱，因此，您將有：myclasslibraryname.Models.Model和myclasslibraryname.Data.Data

來源

2011-02-18 07:16:52

是的。在Java中這是一種常見的做法（至少，我已經看過大型項目的源代碼幾乎總是以這種方式構建的）。在C＃中與我見過的不一樣，但沒有什麼可以阻止你這麼做，它可以幫助你更快地找到代碼。

儘管您可能需要更深層次的命名空間層次結構，而不僅僅是一個層次。在您的組織或組名稱，項目名稱，庫/程序名稱，然後代碼架構名稱（如模型，視圖，數據等）中加上前綴是很常見的。無論對於任何範圍而言，項目的源代碼都將生存在哪個範圍內。

來源

2011-02-18 07:16:55

它* *在C＃中很常用，但只能來自項目的默認名稱空間。查看我的答案，找出差異的一個例子。 – 2011-02-18 07:20:50

一般我認爲這是一個很好的做法。當你這樣做的時候，在通過代碼的時候，你通常可以關聯或者容易地定位並且知道你的代碼文件來自哪裏。

在維護代碼方面，這也是一個很好的做法。有些新用戶進來後，他只能看到名稱空間並確定代碼文件的位置或需要搜索的位置。

來源

2011-02-18 07:17:08

我真的不知道這是否好。但我把它命名爲這樣。我爲不同的模塊定義了類別。

像這樣： Company.Common Company.Common.Web

Company.Windows Company.Windows.Services

共同代表的目錄。在它裏面，我用VS2010創建了一個解決方案。在解決方案中，我爲每個零件創建了一個項目，因此爲項目創建了子目錄，並且如果項目很複雜，dll中現有類的子目錄更多。

那裏我在所有視圖（目錄 - 視圖和項目視圖 - 代碼視圖）中有一個很好的概述。

來源

2011-02-18 07:17:36 YvesR

這是很多項目上有方便的慣例，以及一個其中的一些工具支持或期望。

但是，這不是完整的故事。雖然這是一個很好的違約，但我認爲它不應被視爲不可侵犯的最佳做法，因爲有些情況可能會以另一種方式激勵做事。考慮其他因素包括：

不必要的命名空間擴散和深度嵌套的命名空間層次結構可以爲你的類型的用戶痛。在大型圖書館中，您可能需要開始將源代碼文件組織到某個文件夾結構中，然後您覺得需要在您的客戶端上強加多個名稱空間。
與此相關，在.NET命名空間層次都應該工作，使得類型之間的依賴關係，從孩子的命名空間去父母，而不是其他方式。這並不總是以將源代碼組織成文件夾/目錄的自然方式。例如，一個經常看到人們創造名稱空間通過在MyNamespace.Foo.Bar1 類型和那些MyNamespace.Foo.Bar2同時使用如MyNamespace.Foo.Common 含實用程序的類型。它似乎在源代碼組織級別敏感，但它打破名稱空間依賴約定。
有時你可能想通過加入某些類型的圖書館命名空間分配的輔助組件而不是釋放全庫組件的完全新版本提供附加功能。這很可能是更方便，以保持對各個組件彼此的庫中單獨的源代碼文件，而不是將它們存儲在一起，只是以保持各類在同一個文件夾的命名空間。

總之，我會說按照慣例，除非你有一個很好的理由否則。但是，如果您有充分的理由利用名稱空間可以提供完全正交於其分組到可部署程序集和構建這些程序集的源代碼的類型的分組，則不要讓它威懾到您。

來源

2011-02-18 13:16:48

這是根據目錄名命名命名空間的好實踐

回答

相關問題