148

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

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

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

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

  • 文件夹在命名空间Vehicles中有类MyCompany.Project.Section.Vehicles
  • 文件夹在命名空间Clothing中有类MyCompany.Project.Section.Clothing
  • 等等

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

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

有一些这样的情况是为了“组织方便”而制作文件夹。

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

4

7 回答 7

85

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

这些课程将更容易找到，仅此一项就足够了。

我们遵循的规则是：

  • 项目/程序集名称与根命名空间相同，除了 .dll 结尾
  • 上述规则的唯一例外是带有 .Core 结尾的项目，.Core 被剥离
  • 文件夹等于命名空间
  • 每个文件一种类型（类、结构、枚举、委托等）可以轻松找到正确的文件
于 2008-08-07T12:58:21.267 回答
78

不。

我已经在小型和大型项目中尝试了这两种方法，无论是与单个（我）还是一个开发人员团队。

我发现最简单和最有效的方法是每个项目有一个命名空间，所有类都进入该命名空间。然后，您可以自由地将类文件放入您想要的任何项目文件夹中。由于只有一个命名空间，因此始终在文件顶部添加 using 语句并不麻烦。

将源文件组织到文件夹中很重要，我认为应该使用所有文件夹。要求这些文件夹也映射到命名空间是不必要的，会产生更多的工作，而且我发现实际上对组织有害，因为增加的负担会导致混乱。

以这个 FxCop 警告为例：

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

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

查找文件

接受的答案是“这些课程会更容易找到，仅此一项就足够了。”

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

在任何情况下，虽然您无法从命名空间中确定类文件位于哪个文件夹中，但您可以使用转到定义或 Visual Studio 中的搜索解决方案资源管理器框找到它。在我看来，这也不是一个大问题。我甚至不会将 0.1% 的开发时间花在寻找文件以证明优化它的问题上。

名称冲突

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

  • 类 Project1.Image.Rectangle
  • 类 Project1.Window.Rectangle

可能会遇到源文件需要包含两个命名空间的问题。现在您必须在该文件中的所有位置写出完整的命名空间：

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

或者弄乱一些讨厌的 using 语句：

using Rectangle = Project1.Window.Rectangle;

在您的项目中使用单个命名空间时，您将不得不提出不同的，而且我认为更具描述性的名称，如下所示：

  • 类 Project1.ImageRectangle
  • 类 Project1.WindowRectangle

并且使用在任何地方都是相同的，当文件同时使用两种类型时，您不必处理特殊情况。

使用语句 

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

对比

using Project1;

在编写代码时不必一直添加命名空间的便利性。这不是真正需要的时间，而是不得不这样做的流程中断，只是用大量的 using 语句填充文件——为了什么？这值得么？

更改项目文件夹结构

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

使用项目中的单个命名空间，您可以根据需要更改项目文件夹结构，而无需修改任何源文件本身。

Visual Studio 自动将新文件的命名空间映射到创建它的项目文件夹

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

智能感知和对象浏览器

在我看来，在大型项目中使用多个命名空间的最大好处是在查看任何在命名空间层次结构中显示类的工具中的类时有额外的组织。甚至文档。显然，项目中只有一个命名空间会导致所有类都显示在一个列表中，而不是分成类别。然而，就个人而言，我从来没有因为缺乏这个而被难住或延迟，所以我发现它没有足够大的好处来证明多个命名空间的合理性。

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

于 2015-03-25T12:22:56.320 回答
34

我认为.NET 中的标准是在可能的情况下尝试这样做，而不是创建不必要的深度结构只是为了将其作为硬性规则来坚持。我的项目都没有 100% 地遵循命名空间 == 结构规则，有时它只是更清洁/更好地摆脱这些规则。

在 Java 中，您别无选择。我将其称为理论有效与实践有效的经典案例。

于 2008-08-07T12:58:13.997 回答
25

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

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

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

和

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}
于 2008-09-11T03:45:56.137 回答
6

我会说是的。

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

其次，VS 将生成您在与其父文件夹结构具有相同命名空间的文件夹中创建的新类。如果您决定反对这一点，那么在添加新文件时，每天要做的只是一项额外的管道工作。

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

于 2008-08-07T12:57:13.390 回答
5

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

于 2008-08-07T12:55:17.653 回答
1

标准是什么？

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

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

是的，在大多数类库中，为了便于组织，文件夹与命名空间相匹配。

于 2018-07-15T07:00:30.890 回答