NET：在文件之間划分名稱空間的最佳實踐/指南？

Question

將應用程序代碼（App_Code）划分為單獨文件的一般准則/陷阱應該是什么？

我發現，隨着時間的推移，原始文件與命名空間層次結構的演變方式不匹配。 如何隨着時間的推移直觀地組織應用程序代碼容器？

檔案部門的目標應該是什么？ 代碼可移植性？ 關注點分離？ 一般功能背景？ 變化的頻率？ 他們應該努力與班級建立1-1關系嗎？

將代碼拆分為多個較小的文件與合並為少量文件有什么影響？

我經常想到這一點，但從未真正達成適用於所有情況的任何一般性結論。

Answer 1

這個問題的答案並不是絕對的，因為它通常取決於你手頭的任務。 如果您正在創建某種SDK以供其他人重用，那么名稱空間非常重要; 但是，如果您只使用幾個類創建內部工具，則命名空間幾乎不重要。

類

一般來說，類應該有自己的文件，因為這簡化了人們瀏覽代碼解決方案的方式，有助於開發和維護（例如，當每個人都在更改相同的文件時合並更改會更加困難）。 在某些情況下，將一個類拆分為多個文件是可以接受的，例如：

• 當存在嵌套類時，每個嵌套類都可以擁有自己的文件。

• 當類中有自動生成的部分時，如設計器代碼。

• 當類中有固定部分時，例如一組常見的隱藏屬性或接口的常見實現。

在我們的一個項目中，我們有一個許多類公開的接口的通用實現。 由於我們沒有多重繼承，我們采用混合方法，我們為每個類自動生成一個額外的文件。 這可以手動完成，而不是自動完成（原來是）。

還有其他情況，但這有點主觀，取決於您自己的項目的要求。

命名空間

命名空間通常應該關注類型的合理分組。 命名空間應該允許開發人員直觀地找到他們正在尋找的內容。 對於許多小項目，單個命名空間（如MyAwesomeTool就足夠了，但對於具有許多類的較大項目，則需要更合理的分組。 像SDK或.NET BCL這樣的大型項目依賴命名空間來分解大量的類型。 每個命名空間級別都提供了可能在其中找到的內容的其他信息，例如System.Windows.Forms或System.Drawing或Microsoft.VisualBasic 。

創建名稱空間時，必須考慮到該名稱空間和相關項目的目的。 如果項目是內部的和小的，請調用命名空間你喜歡的，因為它只是分類你的類型的必要條件; 如果項目在外部可見或包含大量類型，請仔細考慮邏輯和有意義的分組，以便其他人能夠直觀地找到他們正在尋找的類型。

結論

在任何情況下都沒有嚴格的規則。 如何將代碼安排到文件中與您自己的開發過程相關，影響您和您的團隊; 你在一個文件中的所有類都將開發，但編譯后的產品不會有任何不同（假設一種文件方法沒有導致錯誤），而你的命名空間的安排與未來的發展和消費者有關。那些名稱空間，所以錯誤的后果可能更嚴重。

• 旨在以簡化當前開發和未來維護的方式組織您的課程。
• 旨在以簡化所有開發的方式組織您的命名空間，並在適當的情況下簡化最終用戶的體驗。

Answer 2

類和源文件之間應該存在一對一的映射。

命名空間應該被視為可以包含一個或多個類的包。 在可能的情況下，在Visual Studio項目窗口中將這些表示為文件夾/過濾器可能很有用。

如果你發現一個相當大的類，你覺得將被分成單獨的文件，然后考慮重構和拆分類本身。

（可接受的）例外是生成Visual Studio放在單獨文件中的UI的代碼。 我建議將其保留在自己的文件中，並盡可能將其視為透明的編輯器擁有的文件。

Answer 3

我看到的大多數建議都說每個公共類型都應該在自己的文件中，名稱空間應該代表應用程序的文件夾結構。

Answer 4

就類而言，我傾向於遵循Java規則：“每個文件一個公共類”如果公共類是唯一用戶，我可以在公共中包含一個私有類。 （雖然，枚舉使這不是一個因素）; 但是，如果它被同一命名空間中的許多公共類使用，那么我將把它放在它自己的文件中。

我傾向於使用命名空間：

MyAwesomeApp.UI
MyAwesomeApp.Business
MyAwesomeApp.Data

反映層的分離。

Answer 5

我做了99％的1到1班來提交。 唯一的例外是如果你有一個大數目或非常簡單的小類，它們都實現相同的接口，不應該改變很多。 您可能希望繼續將這些放在一個文件中。 自定義異常可以是一個很好的例子。 大多數時候（根據我的經驗），除了創建自定義消息或具有這種性質的東西之外，沒有其他代碼。

應首先通過分離關注點來組織命名空間。 例如，Data對象應該位於與域對象不同的命名空間中。 然后，您可能在“聚合根”級別為每組對象設置一個較小的子域。 通常，這些最小的命名空間中的每一個都對應於它自己的項目和DLL。