在 C# 中，创建什么类型、应该拥有什么成员以及应该拥有什么名称空间等问题都是面向对象设计的问题。它们不是我在这里感兴趣的问题。
相反，我想问一下您如何将这些存储在磁盘工件中。以下是一些示例规则：
将程序集的所有类型放在一个源文件中。一位这样做的朋友说“文件是一种古老的代码组织工具；今天我使用 classview 和 Collapse to Definitions 来浏览我的代码”。
将所有代码放在一个程序集中。使部署和版本控制更简单。
目录结构反映命名空间结构。
每个命名空间都有自己的程序集。
每种类型都有自己的程序集。（作为一个极端的例子列出。）
每种类型都有自己的源文件。
每个成员都有自己的文件；每种类型都有自己的目录。（作为一个极端的例子列出。）
无论你做什么，请始终如一地去做。我不相信有任何一个单一的答案（尽管有一些错误的答案）。但请确保您忠实于您的表格，因为这将是您的继任者轻松找到事物的关键。
目前我做：
partial。那是：// ------ C.cs
public partial class C : IFoo
{
// ...
}
// ------ C.Nested.cs
partial class C
{
public class Nested
{
// ...
}
}
我做的很相似。我有一点不同：
- 每个文件一种类型
我在需要它们的地方声明委托类型，即不在它们自己的文件中，而是在使用它们的类中。
我为每个架构层创建一个程序集。（WinUI.exe、BusinessWorkflow.dll、BusinessComponent.dll 等。
然后，每个班级一个物理文件。
这就是“垂直”。
从概念上讲，命名空间是水平的，将域级功能组合在一起。所有客户的东西都放在“客户”命名空间中，例如，订单放在“Accounting.AccountsPayable”中。
由于每个程序集仅引用其下方的程序集 - 在架构上，您的智能感知受到域模型中相关引用的良好约束。
（尽管必须同意上述观点 - 一致性至关重要。
对于少于十二个类的小型项目，每个文件只有一个类。
对于企业项目，我在一个解决方案中有多个项目。它们按用途（业务类、接口、UI）分组。每个类都有自己的文件。
无论类型有多小，都将每种类型放入单独的文件中 - 例外：嵌套类和委托
顺便说一句，仅出于将嵌套类型放置在自己的文件中的目的而使用分部类进行分离似乎有点矫枉过正。部分类应谨慎使用，通常用于文件生成工具 - 您必须考虑如何为嵌套类“命名”部分类。为物理嵌套文件取一个直观的名称可能很麻烦，而且这绝对不是一项简单的任务。
对于项目，命名您的项目以反映命名空间 - 例外：当嵌套命名空间变大时，我会将嵌套文件夹迁移到另一个项目中。
我更喜欢传统的每个公共类一个文件，项目内的文件夹（映射到子目录）用于根据需要对概念上相关的类进行分组，以保持解决方案资源管理器视图的可管理性。如果您的类名选择得当，则文件夹不应该是绝对必要的，但如果项目有很多类，它们会很有帮助。
为嵌套类型使用单独的文件似乎有点过头了，至少如果嵌套类是相对简单的“帮助”类，尤其是如果它们是私有的。
对您朋友的“一个大文件中的所有内容”方案的主要实际反对意见是，Visual Studio 在尝试处理非常长的代码文件时往往会变得非常非常慢。
无论哪种语言，我都喜欢这种组织。
相关的小类在他们自己的文件中。
大类在他们自己的文件中。
单独子项目的目录。