約定 - 具有物理文件夾的項目中的.net命名空間

Question

假設我有一個名為GhostJago.WebScraper的.NET項目

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

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

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

問題： WebScraperAddIn.cs中的namespace GhostJago.WebScraper.AddIns {...}應該是命名namespace GhostJago.WebScraper.AddIns {...}還是無關緊要？

Answer 1

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

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

當時有150種產品，以下是經常出現的情況：

1. 很難找到任何東西
2. 人們在類似類型的產品上工作變得困難（就合並登記而言）（盡管這不是命名空間問題，但這是一個組織問題）
3. 人們變得困惑; 我在哪里添加新的東西？
4. 項目新手不知道從哪里開始

現在，顯然，從編輯器的角度來看，在一個命名空間中擁有大量對象是一件壞事，因為上下文菜單中充滿了各種項目，因此很難查看所需的對象。 因此添加命名空間是一個良好的開端。 但是，將命名空間移動到物理文件夾使得命名空間更容易，特別是在IDE之外。 將類移動到單個文件意味着較小的類幾乎沒有任何合並沖突。 它還使得將文件夾推出到單獨的程序集中變得更加容易。

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

Answer 2

將名稱空間映射到文件夾名稱純粹是慣例。 其目的是在大型項目中更容易找到源代碼。

話雖如此，從技術角度來看，沒有特別的好處或需要來做到這一點。 換句話說，沒關系。

Answer 3

我同意Jon的觀點，總的來說，最好的做法是確保您的命名空間結構與您的物理文件/文件夾結構相匹配，因為它使查找內容變得更容易，您知道類的namespce然后您知道它是什么文件和文件夾好的，你可以去定義，但很容易迷失在一系列定義之后。 但是，如果您有充分的理由不這樣做，就像您希望所有與域相關的類位於同一文件夾中（例如，所有客戶類，訂單類等），但所有DAL類都位於同一名稱空間中，那么就可以了。 主要是通過這些事情，對所有人來說最好的規則是選擇一個慣例並堅持下去。

Answer 4

這樣做的唯一原因是，如果你堅持慣例，它很容易記住，新人會很快接受。 .Net根本不關心，但對我來說問題是為什么我們不能保持簡單。

沒有什么比遺留代碼庫更糟糕了，除了沒有任何其他線索，你甚至不確定代碼在哪里....

Answer 5

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

編輯：

解決方案中的文件夾是否應與命名空間匹配？

約定 - 具有物理文件夾的項目中的.net命名空間