在C＃中，創建什麼類型，應該擁有哪些成員以及應該使用哪些名稱空間等問題是面向對象設計的問題。他們不是我在這裏感興趣的問題。如何將C＃代碼組織到文件中？
相反，我想問你如何將這些存儲在磁盤工件中。以下是一些示例規則：
將所有程序集的類型放入單個源文件中。一位朋友這樣說過：「文件是一種混亂的代碼組織工具;今天我使用classview和Collapse to Definitions來瀏覽我的代碼」。
將所有代碼放在一個程序集中。使部署&版本更簡單。
目錄結構反映名稱空間結構。
每個命名空間都有自己的程序集。
每種類型都有自己的組裝。 （列舉爲一個極端的例子）
每種類型都有它自己的源文件。
每個成員都有自己的文件;每種類型都有自己的目錄。 （列爲一個極端的例子。）
不管你做什麼，只是請去做一致。我不相信有任何單一的答案（雖然有一些錯誤的答案）。但只要確保你忠實於你的表格，因爲這將成爲你的繼任者輕鬆找到事物的關鍵。
目前我做的：
用於生產代碼+單元partial類型。那就是：// ------ C.cs
public partial class C : IFoo
{
// ...
}
// ------ C.Nested.cs
partial class C
{
public class Nested
{
// ...
}
}
我這樣做非常相似。一個地步，我有所不同：每個文件
- 一種類型，我宣佈，我需要他們的委託類型，即不是在他們自己的文件，而是在使用它們的類。
對於少於十幾個班級的小型項目，每個文件只有一個班級。
對於企業項目，我有一個解決方案中的多個項目。它們按目的分組（業務類，界面，UI）。每個班級都有自己的文件。
我更喜歡傳統的one-file-per-public-class，項目中的文件夾（映射到子目錄）用於根據需要對概念上相關的類進行分組，以保持Solution Explorer視圖的可管理性。如果你的班級名稱選擇得當，文件夾不應該是絕對必要的，但是如果項目有很多班級的話，它們會很有幫助。
對嵌套類型使用單獨的文件看起來像是過度殺傷，至少如果嵌套類是相對簡單的'助手'類，尤其是如果它們是私有的。
對你的朋友的「一個巨大文件中的所有內容」方案的主要實際反對意見是，當Visual Studio試圖處理非常長的代碼文件時，它往往變得非常非常慢。
我更喜歡這種組織在任何語言。
自己文件中的相關小類。
在他們自己的文件中的大類。
單獨子項目的目錄。
我爲每個架構層創建一個程序集。 （WinUI.exe，BusinessWorkflow.dll，BusinessComponent.dll等
然後，每類。
一個物理文件，這樣的 「垂直」。
命名空間，概念，去水平，分組域級別所有客戶的東西進入「客戶」名稱空間，例如，訂單進入「Accounting.AccountsPayable」例如
由於每個程序集僅在架構上引用其下方的程序集，因此您的intellisense會受到很好的約束通過您的域名模型中的相關參考文獻
（必須同意上面的說明，但一致性至關重要。
無論一個類型是多麼的渺小，把每種類型到一個單獨的文件 - 例外：嵌套類和代表
順便說一句，使用部分類分開在將嵌套類型的唯一目的它自己的文件似乎是一個矯枉過正的文件。 部分類應明智地使用，通常用於文件生成工具 - 您必須考慮如何爲嵌套類「命名」您的部分類。爲物理嵌套文件提供一個直觀的名字可能會很難，而且這絕對不是一個簡單的任務。
對於項目，請命名您的項目以反映命名空間 - 例外：當嵌套命名空間變大時，我會將嵌套文件夾遷移到另一個項目中。
你想說我們應該保持一致嗎？我不確定。 *咧嘴*好的答案，順便說一句。 – 2008-12-01 23:51:17