在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