来自Java，习惯了包结构（com.domain.appname.tier）
现在我开始研究一个 C# 项目，其中所有项目的深度都是 1：
即
项目A
- 实用程序.cs
- 验证.cs
- ....
- 提取.cs
所有的 cs 文件大约有 2,500 行长......
您如何在 C# 中对类和命名空间进行排序以使其有意义，并使源文件保持逻辑大小？
【问题讨论】：
标签： c# namespaces
就像我在 Java 中想象的那样：
您加入的项目听起来不是很有条理，也不是良好源代码组织的好例子。
【讨论】：
partial class 有效性的问题，这将（显然）导致每个类有多个文件。 （或者可能是反过来，partial class 的设计引发了关于你第二点有效性的问题:)
在 Java 中以类似的方式，您只需要付出一些努力 :) 一些 C# 开发人员，尤其是具有 VB 背景的开发人员，倾向于编写 looooong 类并将它们放在顶层。
【讨论】：
我建议阅读有关该主题的 Microsoft 指南：
Design Guidelines for Developing Class Libraries
特别是您应该查看以下部分：
即使您不编写类库，您仍然可以从这些指南中获益良多。 FxCop（或现在命名的代码分析）将标记许多不符合这些准则的构造。
【讨论】：
我会首先开始将这些类组合到功能区域中，例如授权区域将位于项目中的文件夹下。
然后更新文件夹中类的命名空间以反映更改，Resharper 会为您执行此操作，新版本的 VS 也可能会这样做。
最后（如果你可以的话）我会开始将课程分成更小更易于管理的大小。
【讨论】：
这是我如何组织解决方案的示例，它反映了命名空间结构。
项目有一个默认命名空间，在本例中为 CompanyName.ProjectName 源文件在逻辑上被组织成一个目录结构。在示例中，我的 WF4 活动设计器被组织在一个名为 Designers 的文件夹中的 Activity 下。
VS 的工作方式是，当您在项目中创建目录时，您也在创建命名空间。所以，如果我要在显示的目录中添加一个名为“Foo”的新活动设计器，它的命名空间将是
“CompanyName.ProjectName.Activities.Designers”
Visual Studio 采用默认命名空间，然后使用文件夹结构来确定特定文件的命名空间。当然，一旦创建了文件并移动了文件，它就不会自动重构。但是该系统不仅可以很好地控制类的命名空间，还可以很好地保持文件的组织性。
【讨论】：
与在 Java 中的方式相同。
在 Java 中，包在物理目录中组织类。我不确定这一点，但编译器甚至鼓励这种约定 IIRC。在 C# 中，您不必将类组织到与命名空间匹配的单独目录中，但这是一个非常常见的约定。
说到 C# 中的命名空间，它们不遵循 com.domain.appname.tier 约定，而是使用 Company.Product.Tier 格式。
如何重新组织大型类取决于应用程序。这是一个应用 OOP 指南的练习，适用于 Java 和 C#。
【讨论】：
如果您深入参与该项目，我建议您花一些时间重新设计您在 java 中的结构，考虑到 packages 等同于 namespaces在 C# 中。
【讨论】：