Question

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

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

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

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

文件夹Vehicles在MyCompany.Project.Section.Vehicles命名空间
文件夹Clothing在MyCompany.Project.Section.Clothing命名空间
等

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

文件夹BusinessObjects在MyCompany.Project.Section命名空间

有一些像这样的案例，其中文件夹是为了“组织方便”而制作的。

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

Answer 1

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

这些课程将更容易找到，仅此一点应该是足够好的理由。

我们遵循的规则是：

项目/程序集名称与根名称空间相同，但.dll结尾
上述规则的唯一例外是.Core结尾的项目，.Core被剥离
文件夹等于名称空间
每个文件一个类型（类，结构，枚举，委托等）可以轻松找到正确的文件

Answer 2

没有

我已经在小型和大型项目上尝试了这两种方法，包括单一（我）和一组开发人员。

我发现最简单和最有效的途径是每个项目都有一个命名空间，所有类都进入该命名空间。然后，您可以自由地将类文件放入所需的任何项目文件夹中。由于只有一个命名空间，所以在文件顶部添加使用语句并不是一件容易的事。

将源文件整理到文件夹中很重要，在我看来，应该使用所有文件夹。要求这些文件夹也映射到名称空间是不必要的，创造更多的工作，我发现实际上对组织有害，因为增加的负担会鼓励混乱。

以此FxCop警告为例：

CA1020：避免使用类型较少的命名空间
cause：除全局命名空间以外的命名空间包含的类型少于五种 https://msdn.microsoft.com/en-gb/library/ms182130.aspx

此警告鼓励将新文件转储到通用Project.General文件夹，甚至是项目根目录，直到您有四个类似的类来证明创建新文件夹的合理性。这会发生吗？

查找文件

接受的答案说＆＃34;这些课程更容易找到，而且这一点应该足够好。＆＃34;

我怀疑答案是指项目中有多个名称空间没有映射到文件夹结构，而不是我建议哪个是具有单个名称空间的项目。

在任何情况下，您无法从命名空间确定类文件所在的文件夹，您可以使用“转到定义”或Visual Studio中的搜索解决方案资源管理器框找到它。在我看来，这并不是一个很大的问题。我不会花费0.1％的开发时间来查找文件以证明优化它的合理性。

名称冲突

确保创建多个名称空间允许项目具有两个具有相同名称的类。但这真的是件好事吗？是否可能更容易禁止这种可能性？允许两个具有相同名称的类会创建一个更复杂的情况，其中90％的时间事情以某种方式工作，然后突然您发现您有一个特殊情况。假设您在不同的命名空间中定义了两个Rectangle类：

class Project1.Image.Rectangle
class Project1.Window.Rectangle

可能遇到源文件需要包含两个命名空间的问题。现在你必须在该文件中的任何地方写出完整的命名空间：

var rectangle = new Project1.Window.Rectangle();

或者使用一些令人讨厌的使用声明：

using Rectangle = Project1.Window.Rectangle;

在项目中使用单个命名空间时，您不得不提出不同的命名空间，我认为这些名称更具描述性：

class Project1.ImageRectangle
class Project1.WindowRectangle

在任何地方使用都是一样的，当文件同时使用这两种类型时，你不必处理特殊情况。

使用陈述

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;

VS

using Project1;

在编写代码时不必一直添加命名空间。它不是真正需要的时间，它是必须要做的流程的中断，只是用大量的使用语句来填充文件 - 为了什么？值得吗？

更改项目文件夹结构

如果文件夹映射到名称空间，则项目文件夹路径实际上硬编码到每个源文件中。这意味着项目中任何文件或文件夹的重命名或移动都需要更改实际文件内容。该文件夹中文件的名称空间声明以及在引用该文件夹中的类的一大堆其他文件中使用语句。虽然变化本身对于工具来说是微不足道的，但它通常会导致一个由许多文件组成的大型提交，这些文件的类甚至都没有改变。

使用项目中的单个命名空间，您可以更改项目文件夹结构，但不需要修改任何源文件。

Visual Studio会自动将新文件的命名空间映射到它在

中创建的项目文件夹

不幸的是，但我发现纠正命名空间的麻烦不如处理它们的麻烦。我也养成了复制粘贴现有文件的习惯，而不是使用Add-＆gt; New。

智能感知和对象浏览器

我认为在大型项目中使用多个命名空间的最大好处是，在任何显示命名空间层次结构中的类的工具中查看类时，需要额外的组织。甚至文件。显然，在项目中只有一个命名空间会导致所有类显示在单个列表中而不是分成类别。不过个人而言，由于缺乏这一点，我从来没有感到难过或耽误，所以我发现它不足以证明多个名称空间的合理性。

虽然如果我正在编写一个大型公共类库，那么我可能会在项目中使用多个名称空间，以便程序集在工具和文档中看起来很整洁。

Answer 3

我认为.NET中的标准是尽可能地尝试这样做，但不要创建不必要的深层结构只是为了坚持它作为一个硬性规则。我的项目都没有100％的时间遵循命名空间==结构规则，有时它只是更清洁/更好地突破这些规则。

在Java中你没有选择。我称之为理论上与实践中有效的经典案例。

Answer 4

@lassevk：我同意这些规则，还有一个要添加。

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

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

和

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

Answer 5

我会说是的。

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

其次，VS将生成您在其父文件夹结构具有相同名称空间的文件夹中创建的新类。如果你决定对此游泳，那么在添加新文件时，每天只需要做一个管道工作。

当然，不言而喻，对于xis文件夹/命名空间层次结构的深度，人们应该保守。

Answer 6

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

Answer 7

什么是标准？

没有官方标准，但通常使用最广泛的文件夹到名称空间映射模式。

在类库中，文件夹通常与名称空间匹配吗结构还是混合袋？

是的，在大多数类库中，文件夹都与名称空间匹配，以便于组织使用。

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

7 个答案: