如何将C＃代码组织到文件中？

在C＃中，关于要创建什么类型，应该拥有哪些成员以及应该拥有哪些名称空间的问题是OO设计的问题。它们不是我在这里感兴趣的问题。

相反，我想问一下如何将这些存储在磁盘工件中。以下是一些示例规则：

将所有程序集的类型放在单个源文件中。一位做过此事的朋友说“文件是一个架构代码组织工具;今天我使用classview和Collapse to Definitions来浏览我的代码”。
将所有代码放在一个程序集中。使部署和版本控制更简单。
目录结构反映命名空间结构
每个命名空间都有自己的程序集
每种类型都有自己的组装。（列为一个极端的例子。）
每种类型都有自己的源文件。
每个成员都有自己的文件; 每种类型都有自己的目录。（列为一个极端的例子。）

无论你做什么，请坚持不懈地做。我不相信有任何一个答案（虽然有一些错误的答案）。但只要确保你坚持自己的forms，因为这将是你的继任者轻松找到事情的关键。

目前我这样做：

 // ------ C.cs public partial class C : IFoo { // ... } // ------ C.Nested.cs partial class C { public class Nested { // ... } }

我这样做很相似。我不同的一点：

每个文件一种类型

我在需要它的地方声明委托类型，即不在它们自己的文件中，而是在使用它们的类中。

我为每个架构层创建一个程序集。（WinUI.exe，BusinessWorkflow.dll，BusinessComponent.dll等。

然后，每个类一个物理文件。

所以这是“垂直的”。

从概念上讲，命名空间是水平的，将域级function组合在一起。所有客户的东西都在“客户”命名空间中，例如，订单进入“Accounting.AccountsPayable”。

因为每个程序集只引用它下面的那个 – 在架构上，你的intellisense在你的域模型中被相关引用很好地约束。

（但必须同意上述内容 – 一致性至关重要。

对于少于十几个类的小型项目，每个文件只有一个类。

对于企业项目，我在解决方案中有多个项目。它们按目的分组（业务类，接口，UI）。每个类都有自己的文件。

无论类型多小，都将每个类型放入一个单独的文件中 – 例外：嵌套类和委托

顺便说一下，使用部分类来分离，其唯一目的是将嵌套类型放在自己的文件中，这似乎是一种矫枉过正。部分类应该明智地使用，通常用于文件生成工具 – 您必须考虑如何为嵌套类“命名”您的部分类。为物理嵌套文件提供直观的名称可能是非常有趣的，它绝对不是一项简单的任务。

对于项目，将项目命名为反映命名空间 – 例外：当嵌套命名空间变大时，我会将嵌套文件夹迁移到另一个项目中。

我更喜欢传统的one-file-per-public-class，项目中的文件夹（映射到子目录）用于根据需要对概念上相关的类进行分组，以保持Solution Explorer视图的可管理性。如果您的类名被很好地选择，那么文件夹不应该是绝对必要的，但如果项目有很多类，它们会很有用。

对于嵌套类型使用单独的文件似乎有点过分，至少如果嵌套类是相对简单的“帮助”类，特别是如果它们是私有的话。

对你朋友的“一个大文件中的所有东西”方案的主要实际反对意见是，当Visual Studio试图处理很长的代码文件时，它往往变得非常非常慢。

无论用哪种语言，我都喜欢这种组织。

相关的小类在他们自己的文件中。

他们自己的文件中的大class。

单独子项目的目录。