惯例 - 在项目.NET命名空间与物理文件夹

假设我有一个名为GhostJago.WebScraper惯例 - 在项目.NET命名空间与物理文件夹

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

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

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

问：应在WebScraperAddIn.cs命名空间是namespace GhostJago.WebScraper.AddIns {...}或者它没有关系？

来源

2011-12-20 ghostJago

这绝对没关系。您不必将名称空间映射到物理文件夹。 – 2011-12-20 12:22:01

这是ReSharper方式（和某种惯例）。但正如科迪所说，选择是你的选择。 – Koen 2011-12-20 12:31:34

清洁房间并不重要。直到你需要找到一些东西。 – dash 2011-12-20 13:33:37

这绝对是做了一件好事，让我给你一个反对的例子，说明如何不使用它可能是不好的

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

通过共有150个产品的时候，下面是一个普通occurence：

它变得很难找到任何
它变得困难（在合并上签方面）的人去努力类似的产品（虽然这不是一个命名空间问题，但它是一个组织问题）
人们变得困惑;我在哪里添加新的东西？
人们新的项目并没有从哪里开始

现在，很明显的想法，从一个编辑点，有大量的对象在一个命名空间一件坏事，因为上下文菜单的都装满物品，因此很难看到你想要的。因此添加名称空间是一个好的开始。但是，将名称空间移动到物理文件夹使得更容易导航命名空间，尤其是在IDE之外。将类移动到单个文件意味着更小的类，几乎没有任何合并冲突。它还使开始将文件夹推送到单独的程序集变得更加容易。

因此，在您的项目中拥有一定程度的组织可以让事情变得更简单！

来源

2011-12-20 13:29:10 dash

+1为负面的例子 – ghostJago 2011-12-20 13:47:18

-1

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

编辑：

Should the folders in a solution match the namespace?

convention - .net namespaces in projects with physical folders

来源

2011-12-20 12:24:51

因为...？为什么这是最佳做法？为了有用，这样的声明需要某种理由。 – 2011-12-20 12:32:32

你有你的声明的链接/参考吗？我会很感兴趣，因为我可以提供这个作为我想做的一些改变的理由。 – ghostJago 2011-12-20 13:51:28

映射名称空间的文件夹名称是纯粹的约定。其目的是在大型项目中查找源代码更简单。

这就是说，从技术角度来看，没有特别的好处或需要做到这一点。换句话说，这并不重要。

来源

2011-12-20 12:26:01

我同意Jon的观点，总体上最好的做法是确保您的命名空间结构与您的物理文件/文件夹结构相匹配，因为它使查找更容易，您知道类的名称，然后知道该文件和它所在的文件夹。好吧，你已经进入了定义阶段，但是在定义链之后很容易迷路。然而，如果你有充分的理由不这样做，就像你想要所有与域相关的类在同一个文件夹中（例如所有的客户类，订单类等），但是所有的DAL类在相同的名称空间中那么它就没有问题。主要是对这些事情来说，最好的规则是选择一个惯例并坚持下去。

来源

2011-12-20 12:38:12

这样做的唯一理由是，如果你坚持这个约定，那么很容易记住，而新人会快速地选择一些东西。 .Net根本不在乎，但对我来说问题是为什么我们不能保持简单。比传统的代码库，其中还有没有其他任何线索，你甚至不知道在哪里的代码更糟糕的是

没什么....

来源

2011-12-20 12:39:35

惯例 - 在项目.NET命名空间与物理文件夹

回答

相关问题