我正在开发一个MVVM项目，所以我的项目中有像Models，ViewModels，Windows等文件夹。每当我创建一个新类时，Visual Studio会自动将文件夹名称添加到命名空间名称而不是保留项目级命名空间。因此，向ViewModels文件夹添加新类将导致命名空间MyProject.ViewModels，而不仅仅是MyProject。
当我第一次遇到这个时，它让我恼火。我的班级名称非常清楚，有时甚至包含其中的文件夹名称（例如ContactViewModel）。我很快发现自己手动删除名称空间上的文件夹名称。我甚至尝试过创建一个自定义类模板（参见this question），但我无法让它工作，所以继续手动操作。
问题：
答案 0 :(得分：46)
和你一样 - 我打了很长时间。然后我开始考虑为什么我创建了文件夹。我发现自己开始创建文件夹来表示命名空间和包而不是任意存储桶。
例如，在MVVM项目中，将视图和视图模型放在单独的命名空间中可能会有所帮助。 MVC将为模型，控制器和视图提供单独的命名空间。通过其功能对类进行分组也是有益的。
突然间，该项目感觉更有条理。其他开发人员更容易找到功能的实现位置。
如果您对命名空间实践进行标准化，那么您的所有项目都将具有相同的可预测结构，这将是维护的一大胜利。
答案 1 :(得分：17)
如果您需要一些可靠的建议，我建议您购买Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries，这样您就可以从实际的框架设计团队中获得所需的一切。
...命名命名空间时的目标是为程序员创建足够的清晰度，使用框架立即知道命名空间的内容可能是什么......
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
而且重要的是
不要对命名空间使用相同的名称，并在该命名空间中使用类型
将每1/2个类型分段为命名空间将不符合第一个要求，因为如果您遵循Visual Studio方式，您将拥有必须限定或使用的命名空间沼泽。例如
核心 - 域名 - 用户 - 权限 - 帐户
你会创建
吗？或只是
对于Visual Studio来说，它将成为前者。此外，如果您使用小写文件/文件夹命名，则每次都要重命名该类，以及使一个大的命名空间纠结。
大多数情况都是常识，而且如果你是您自己的API或框架的消费者，那么您希望如何看待命名空间的组织。
答案 2 :(得分：10)
我对此感到恼火，但是使用大型代码库进行工作和重构项目很快就教会了我。接受了这个概念后，我认为这是一种非常好的方式来“物理”和逻辑地构建代码。当您有一个大型项目并且命名空间与文件夹不匹配时，很难快速找到文件。还有更难以记住的事情......
另外，如果ReSharper推荐它，那么这可能是一个好主意。例如。如果您的类名称空间与其文件夹名称不匹配，R＃将会抱怨。
答案 3 :(得分：5)
不遵循惯例的一种方法是在项目根文件夹中创建文件，然后将其移动到最终的子文件夹。
无论如何，这是我真正喜欢的惯例。如果我将类型拆分为文件夹，则可能这些类型具有与该文件夹相关的某种概念分组。因此，它结束了一些意义，它们的命名空间也类似。 Java采用这种方法并使用其包系统强制执行它。最大的区别是VS只是“向你建议”，因为语言或CLR都没有强制执行它。
答案 4 :(得分：5)
文件系统文件夹和命名空间都代表层次结构。我似乎很自然地匹配这两者。我甚至更进一步，在文件和类之间使用1：1的关系。当我使用其他语言（如C ++）进行编程时，我甚至会这样做。
现在你质疑这两个层次结构之间的关系，我真的很想知道你想用文件系统层次结构代表什么。
答案 5 :(得分：4)
虽然我同意其他人的意见，但是与逻辑结构相匹配的物理结构是有帮助的，我不得不说我也会使用Visual Studio的自动命名。我必须重命名课程有六个原因：
由于这些原因，我已经让自己不得不为我创造的每个班级调整这些。我避免这个问题的策略是复制一个具有我想要的命名空间声明的文件，然后立即删除内容。
答案 6 :(得分：3)
在C ++中引入名称空间之前，所有C类型都在全局名称空间中。创建命名空间是为了将类型分隔为逻辑容器，因此很清楚要引用的类型。这也适用于C＃。
程序集是部署决策。如果查看.Net框架，给定的程序集将包含多个不同的名称空间。
文件夹用于组织磁盘上的文件。
这三者之间没有任何关系，但是，程序集名称，命名空间和文件夹名称相同通常很方便。请注意，Java折叠文件夹和命名空间是相同的（限制了开发人员组织文件和命名空间的自由）。
我们经常选择将项目中的文件组织到多个文件夹中，因为我或我的团队更容易浏览文件。通常，此文件组织与我们使用的命名空间设计无关。我希望VS团队不会将命名空间默认为与文件夹名称相同，或者至少将选项返回到不具有默认值。
不要受苦，要么在创建新文件后更改新类的模板，要么更正名称空间。
答案 7 :(得分：2)
我也感觉到Visual Studio中这种'默认'行为的痛苦。
当您将LinqToSql .dbml文件放在它们自己的目录中时，Visual Studio也会尝试设置命名空间/目录匹配。每当我编辑.dbml时，我都要记得：
.dbml.designer.cs文件namespace声明但是有一种方法stop this behaviour。它涉及创建自定义类模板。
答案 8 :(得分：2)
我认为确实存在命名空间和项目文件夹的不同结构的正当理由。如果您正在开发一个库，那么命名空间结构应首先为您的API的用户提供服务：它应该是合乎逻辑且易于掌握的。另一方面，文件夹结构应主要为您提供便利， API设计器。有些目标确实非常相似，因为结构也应该是合乎逻辑的。但也可能有不同的，例如您可以快速选择相关文件进行加工，或者易于导航。例如，我自己会在达到某个文件阈值时创建新文件夹，否则找到我正在寻找的文件只需要很长时间。但尊重设计师的偏好也可能意味着严格遵循命名空间 - 如果这是他们的偏好。
总的来说，在很多情况下，两者都匹配是有道理的，但我认为存在偏离的有效案例。
过去对我有用的是在一个地方创建一个文件（例如WPF UserControl）以使命名空间正确，然后将其移动到＆＃34;右边＆＃34;文件夹中。
答案 9 :(得分：0)
虽然我同意将命名空间层次结构与文件夹层次结构相匹配非常方便，但我认为Visual Studio似乎不支持关闭此功能的事实令人作呕。 Visual Studio有很多应用程序，并且有很多编码样式和结构化源文件夹的方法非常好。
假设存在数千个属于命名空间的文件，但程序员只想将它们分组到文件夹中以使层次结构更易于导航。这真是个坏主意吗？这真的会让事情变得如此难以维护，以至于它应该被IDE禁止吗？
假设我使用Visual Studio与Unity合作。现在，我的所有脚本都在“Assets.Scripts”命名空间中。不仅有一个无用的Assets命名空间现在不包含脚本，但“Assets.Scripts”没有意义 - 它没有描述源文件属于哪个项目或项目的一部分。无用。