慣例 - 在項目.NET命名空間與物理文件夾

假設我有一個名爲GhostJago.WebScraper慣例 - 在項目.NET命名空間與物理文件夾

在這個項目中我有一個包含一個類，WebScrapeEngine文件的.NET項目。該課程包含在namespace GhostJago.WebScraper {...}中。

現在我添加一個新文件夾，並在該文件夾中放置一個類文件。我的結構基本上是：

GhostJago.WebScraper (Project) 
|-> AddIns (folder) 
    |-> WebScraperAddIn.cs (c# file) 
|-> WebScraperEngine.cs (c# file)

問：應在WebScraperAddIn.cs命名空間是namespace GhostJago.WebScraper.AddIns {...}或者它沒有關係？

來源

2011-12-20 ghostJago

這絕對沒關係。您不必將名稱空間映射到物理文件夾。 – 2011-12-20 12:22:01

這是ReSharper方式（和某種慣例）。但正如科迪所說，選擇是你的選擇。 – Koen 2011-12-20 12:31:34

清潔房間並不重要。直到你需要找到一些東西。 – dash 2011-12-20 13:33:37

這絕對是做了一件好事，讓我給你一個反對的例子，說明如何不使用它可能是不好的

我工作在一個幾年前處理各種產品的系統。所有這些都在文件夾Company.System.Products中。實際上，這個文件夾中的許多類在一個cs文件中也有多個類。

通過共有150個產品的時候，下面是一個普通occurence：

它變得很難找到任何
它變得困難（在合併上籤方面）的人去努力類似的產品（雖然這不是一個命名空間問題，但它是一個組織問題）
人們變得困惑;我在哪裏添加新的東西？
人們新的項目並沒有從哪裏開始

現在，很明顯的想法，從一個編輯點，有大量的對象在一個命名空間一件壞事，因爲上下文菜單的都裝滿物品，因此很難看到你想要的。因此添加名稱空間是一個好的開始。但是，將名稱空間移動到物理文件夾使得更容易導航命名空間，尤其是在IDE之外。將類移動到單個文件意味着更小的類，幾乎沒有任何合併衝突。它還使開始將文件夾推送到單獨的程序集變得更加容易。

因此，在您的項目中擁有一定程度的組織可以讓事情變得更簡單！

來源

2011-12-20 13:29:10 dash

+1爲負面的例子 – ghostJago 2011-12-20 13:47:18

-1

確保您的名稱空間結構與您的物理文件/文件夾結構相匹配是最佳做法。

編輯：

Should the folders in a solution match the namespace?

convention - .net namespaces in projects with physical folders

來源

2011-12-20 12:24:51

因爲...？爲什麼這是最佳做法？爲了有用，這樣的聲明需要某種理由。 – 2011-12-20 12:32:32

你有你的聲明的鏈接/參考嗎？我會很感興趣，因爲我可以提供這個作爲我想做的一些改變的理由。 – ghostJago 2011-12-20 13:51:28

映射名稱空間的文件夾名稱是純粹的約定。其目的是在大型項目中查找源代碼更簡單。

這就是說，從技術角度來看，沒有特別的好處或需要做到這一點。換句話說，這並不重要。

來源

2011-12-20 12:26:01

我同意Jon的觀點，總體上最好的做法是確保您的命名空間結構與您的物理文件/文件夾結構相匹配，因爲它使查找更容易，您知道類的名稱，然後知道該文件和它所在的文件夾。好吧，你已經進入了定義階段，但是在定義鏈之後很容易迷路。然而，如果你有充分的理由不這樣做，就像你想要所有與域相關的類在同一個文件夾中（例如所有的客戶類，訂單類等），但是所有的DAL類在相同的名稱空間中那麼它就沒有問題。主要是對這些事情來說，最好的規則是選擇一個慣例並堅持下去。

來源

2011-12-20 12:38:12

這樣做的唯一理由是，如果你堅持這個約定，那麼很容易記住，而新人會快速地選擇一些東西。 .Net根本不在乎，但對我來說問題是爲什麼我們不能保持簡單。比傳統的代碼庫，其中還有沒有其他任何線索，你甚至不知道在哪裏的代碼更糟糕的是

沒什麼....

來源

2011-12-20 12:39:35

慣例 - 在項目.NET命名空間與物理文件夾

回答

相關問題