C# 中的命名空間

Question

我正在使用 ASP.NET MVC 項目，每次我將 class 添加到文件夾時，它都會產生非常長的命名空間。

示例：

Project = Tully.Saps.Data  
Folder = DataAccess/Interfaces  
Namespace = Tully.Saps.Data.DataAccess.Interfaces

Folder = DataAccess/MbNetRepositories  
Namespace = Tully.Saps.Data.DataAccess.MbNetRepositories

問題：
是否最好單獨保留命名空間並將 using 子句添加到訪問它的類或將命名空間更改為 Tully.Saps.Data 以用於此項目中的所有內容？

Answer 1

不理會它們並添加使用。 您在手動更改類似的東西時遇到麻煩（更難調試，與其他項目不一致，等等）。

Answer 2

你想如何處理它真的取決於你。 如果您只打算訪問一個名稱空間的成員一次或兩次，那么添加“using”語句對您來說並沒有多大用處。

如果您要多次使用它，那么減少命名空間鏈可能會使事情更容易閱讀。

如果您只是想在邏輯上將文件分組在一起，而不創建新的命名空間，您可以隨時更改命名空間，這樣它就不會添加新的文件夾名稱。

Answer 3

根據 FXCop，我同意：

避免使用少數類型的命名空間

一個命名空間通常應該有五種以上的類型。

也（這適用於“單一命名空間”的建議——這幾乎等同於沒有命名空間）

在命名空間中聲明類型

應在命名空間內定義類型以避免重復。

Answer 4

• 命名空間

.Namespaces 幫助我們在 object model 或我們的應用程序中定義一組實體的“范圍”。 這使它們成為軟件設計決策而不是文件夾結構決策。 例如，在 MVC 應用程序中，擁有 Model/View/Controller 文件夾和相關的命名空間是很有意義的。 因此，雖然在某些情況下，文件夾結構可能與我們決定在開發中使用的命名空間模式相匹配，但這不是必需的，也可能不是我們想要的。 每個命名空間都應根據具體情況決定

• 使用語句

為命名空間定義 using 語句是一個單獨的決定，具體取決於代碼中引用該命名空間中 object 的頻率，並且不應以任何方式影響我們的命名空間創建實踐。

Answer 5

別管它。 這是您的 IDE 如何決定您的編碼風格的一個很好的例子。

Answer 6

僅僅因為您使用的工具 (Visual Studio) 決定每個文件夾都需要一個新的命名空間並不意味着您需要這樣做。
我個人傾向於將我的“數據”項目保留為單個命名空間。 如果我有一個名為“Model”的子文件夾，我不希望這些文件位於 Something.Data.Model 命名空間中，而是希望它們位於 Something.Data 中。