约定- .net名称空间项目中的物理文件夹

本文关键字：文件夹 项目 空间 net 约定 | 更新日期: 2023-09-27 18:18:35

假设我有一个名为GhostJago.WebScraper的。net项目

在这个项目中，我有一个包含类WebScrapeEngine的文件。类包含在namespace GhostJago.WebScraper {...}中。

现在我添加一个新文件夹，并在该文件夹中放入一个类文件。我的结构基本上是:

GhostJago.WebScraper (Project)
 |-> AddIns (folder)
    |-> WebScraperAddIn.cs (c# file)
 |-> WebScraperEngine.cs (c# file)

问题:应该在WebScraperAddIn.cs名称空间是namespace GhostJago.WebScraper.AddIns {...}或不重要?

约定- .net名称空间项目中的物理文件夹

这绝对是一件好事，让我给你一个相反的例子来说明不使用它是不好的

几年前我开发过一个系统，它处理各种各样的产品。所有这些都在Company.System.Products文件夹中。事实上，这个文件夹中的许多类在一个cs文件中也有多个类。

当有150种产品时，以下是经常发生的:

  1. 很难找到任何东西
  2. 人们在类似类型的产品上工作变得困难(就合并签入而言)(尽管这不是名称空间问题，这是一个组织问题)
  3. 人们变得困惑;我在哪里添加新的东西?
  4. 项目的新手不知道从哪里开始

现在，显然，从编辑器的角度来看，在一个名称空间中有许多对象是一件坏事，因为上下文菜单中充满了项目，使得很难看到您想要的那个。因此，添加名称空间是一个良好的开端。但是，将名称空间移动到物理文件夹中可以更容易地导航名称空间，特别是在IDE之外。将类移到单独的文件中意味着更小的类，几乎没有合并冲突。它还使开始将文件夹推出到单独的程序集中变得更加容易。

所以在你的项目中有一定程度的组织可以让事情变得更容易!

将名称空间映射到文件夹名称纯粹是惯例。它的目的是使在大型项目中查找源代码更容易。

也就是说，从技术角度来看，这样做没有特别的好处或需要。换句话说，这无关紧要。

我同意Jon的观点，总的来说，确保你的命名空间结构与你的物理文件/文件夹结构匹配是最佳实践，因为它使查找东西更容易，你知道一个类的命名空间，然后你知道它在哪个文件和文件夹中。好的，你要找到定义，但是很容易迷失在一系列的定义中。但是，如果你有一个很好的理由不这样做，就像你想要所有与域相关的类在同一个文件夹中(例如，所有的客户类，订单类等)，但所有的DAL类在同一个命名空间中，那么它是好的。对于这些事情，最好的规则是选择一个惯例并坚持下去。

这样做的唯一原因是，如果你坚持惯例，它很容易记住，新的人会很快学会。net根本不在乎，但对我来说，问题是为什么我们不能保持简单。

没有什么比遗留代码库更糟糕的了，除了没有任何其他线索，您甚至不确定代码在哪里....

确保您的名称空间结构与您的物理文件/文件夹结构匹配是最佳实践。

编辑:

解决方案中的文件夹应该与名称空间匹配吗?

约定-带有物理文件夹的项目中的。net命名空间

相关文章：