解决方案中的文件夹是否应与名称空间匹配？

在我的一个团队项目中，我们有一个类库，该类库在项目中包含许多子文件夹。

项目名称和命名空间：MyCompany.Project.Section。

在该项目中，有几个与"名称空间"部分匹配的文件夹：

• 文件夹" Vehicles"在" MyCompany.Project.Section.Vehicles"命名空间中具有类
• 文件夹"服装"在MyCompany.Project.Section.Clothing`命名空间中具有类
• 等等。

在同一项目中，是另一个流氓文件夹

• 文件夹" BusinessObjects"在" MyCompany.Project.Section"命名空间中具有类。

在某些情况下，为了"组织上的方便"而制作文件夹。

我的问题是：什么标准？在类库中，文件夹通常与名称空间结构匹配还是混在一起？

解决方案

回答

是的，他们应该这样做，否则只会导致混乱。

回答

我会说是的。

首先，通过遵循名称空间(例如，当有人通过电子邮件向我们发送裸异常调用堆栈)来查找实际的代码文件时会更容易。如果我们让文件夹与命名空间不同步，那么在大型代码库中查找文件将变得很累人。

其次，VS将在与父文件夹结构相同的名称空间的文件夹中生成我们创建的新类。如果我们决定不这样做，那么添加新文件时，每天要做的只是一项繁琐的工作。

当然，这毋庸置疑，对于xis文件夹/命名空间层次结构的深入程度，应该保持保守。

回答

我认为.NET中的标准是尝试在可能的情况下做到这一点，而不是创建不必要的深层结构，而只是作为硬性规则坚持下去。我的项目中没有一个100％的时间遵循命名空间==结构规则，有时它更干净/更好地脱离此类规则。

在Java中，我们别无选择。我称这是理论上有效与实践上有效的经典案例。

回答

另外，请注意，如果我们使用内置模板将类添加到文件夹，则默认情况下会将其放置在反映文件夹层次结构的命名空间中。

这些类将更容易找到，仅凭其应是足够好的理由。

我们遵循的规则是：

• 项目/程序集名称与根名称空间相同，除了.dll结尾
• 上述规则的唯一例外是项目以.Core结尾，.Core被剥离
• 文件夹等于名称空间
• 每个文件一种类型(类，结构，枚举，委托等)使查找正确的文件变得容易

回答

@lassevk：我同意这些规则，还有一点要补充。

当我有嵌套的类时，我仍然将它们拆分出来，每个文件一个。像这样：

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

和

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}