我应该停止对抗Visual Studio的默认命名空间命名约定？
我正在开发一个MVVM项目，所以我的项目中有像Models，ViewModels，Windows等文件夹。每当我创build一个新类时，Visual Studio都会自动将文件夹名称添加到名称空间中，而不是只保留项目 – 级别的命名空间。 所以，向ViewModels文件夹添加一个新的类将导致命名空间MyProject.ViewModels而不仅仅是MyProject 。
当我第一次遇到这个时，它使我烦恼。 我的类名非常清晰，有时甚至包含文件夹的名称（例如， ContactViewModel ）。 我很快发现自己手动删除名称空间上的文件夹名称。 我什至试图创build一个自定义的类模板（见这个问题 ），但我不能得到这个工作，所以继续手动做。
但是，我开始怀疑，如果这个惯例存在，我只是没有看到一个很好的理由。 如果由于某种原因，有许多相同的类名被组织到文件夹中，我可以看到它是有用的，但这似乎并不是特别常见的情况。
问题：
- 为什么命名空间名称的公共约定反映文件夹结构？
- 你遵守这个惯例吗？ 为什么？
和你一样 – 我打了这么久的时间。 然后我开始考虑为什么我创build了文件夹。 我发现自己开始创build文件夹来表示名称空间和包，而不是任意的桶。
例如，在MVVM项目中，将视图和视图模型放在单独的命名空间中可能会有所帮助。 MVC将有一个独立的模型，控制器和视图的命名空间。 按class级分class也是有好处的。
突然间，项目感觉更有组织。 其他开发人员更容易findfunction的实现。
如果您对您的名称空间实践进行标准化，那么您的所有项目都将具有相同的可预测结构，这将是维护的一大胜利。
如果你需要一些可靠的build议，我build议购买框架devise指南：可重用的.NET库的约定，成语和模式，这给你所有你需要从实际的框架devise团队知道。
命名空间的目标是为程序员创build足够的清晰度，使用框架立即知道命名空间的内容可能是什么…
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
而且重要的是
不要在名称空间中使用相同的名称作为名称空间和types
如果你遵循Visual Studio的方式，每个1/2types碎片化到命名空间中将不会满足第一个要求，因为你将会有一堆必须被限定或使用的命名空间。 例如
核心 – 域 – 用户 – 权限 – 帐户
你会创造吗？
- MyCompany.Core.Domain.Users
- MyCompany.Core.Domain.Permissions
- MyCompany.Core.Domain.Accounts
要不就
- MyCompany.Core.Domain
对于Visual Studio的方式，这将是前者。 另外，如果你使用小写的文件/文件夹命名，你每次都要重新命名类，以及使一个大的命名空间纠结。
大部分是常识，真正取决于如果你是自己的API或框架的消费者，你将如何看待命名空间的组织。
我也为此感到恼火，但与大型代码库合作并重构项目很快就教会了我。 接受了这个概念之后，我认为这是一种非常好的方法来“物理”和逻辑地构build代码。 当你有一个大项目，名称空间不匹配的文件夹很难find文件很快。 这也是更难以记住的地方…
另外，如果ReSharper推荐它，那么这可能是一个好主意。 例如，如果您的class级的名称空间与其文件夹名称不匹配，则R＃将会投诉。
文件系统文件夹和名称空间都表示一个层次结构。 我看起来很自然地匹配这两个。 我甚至更进一步，在文件和类之间使用1：1的关系。 我甚至在用C ++等其他语言编程时也这样做。
现在，您质疑这两个层次之间的关系，我真的很想知道您希望通过文件系统层次结构表示什么。
不遵循惯例的一种方法是在项目根文件夹中创build文件，然后将其移动到最终的子文件夹。
无论如何，这是一个我实际上喜欢的约定。 如果我将文件拆分成文件夹，那么可能这些types有一些与该文件夹相关的概念分组。 因此，它结束了一些道理，它们的命名空间也是相似的。 Java采用这种方法并通过其包系统来执行它。 最大的区别是VS只是“向你提供”，因为语言和CLR都没有强制执行它。
虽然我同意其他人的意见，但是与逻辑结构匹配的物理结构是有帮助的，我不得不说我也与Visual Studio的自动命名作斗争。 有六个原因，我必须重新命名类：
- 我使用根“src”文件夹来将我的代码从embedded式资源中直观地分离出来
- 我想要不同的大写
- 我将把我的代码组织到一个名字空间中的组织子文件夹中
- 我喜欢从实现和基类中分离接口
- 我感觉像
由于这些原因，我已经辞职了，不得不为每个创build的课程调整这些。 我避免这个问题的策略是复制一个具有我想要的名称空间声明的文件，然后立即删除这些内容。
在C ++中引入名称空间之前，所有Ctypes都在全局名称空间中。 命名空间是为了将types分离到逻辑容器而创build的，所以清楚了什么types被引用。 这也适用于C＃。
组件是一个部署决策。 如果您看.Net框架，给定的程序集将包含多个不同的名称空间。
文件夹是组织磁盘上的文件。
这三者没有任何关系，但是，程序集名称，名称空间和文件夹名称是相同的。 请注意，Java折叠文件夹和名称空间是相同的事情（限制开发人员组织文件和名称空间的自由）。
通常我们select将项目中的文件组织到多个文件夹中，因为我或我的团队更容易导航文件。 通常这个文件组织与我们使用的命名空间devise无关。 我希望VS团队不要默认命名空间与文件夹名称相同，或者至less给选项返回，不要将其设置为默认值。
不要忍受，要么改变新类的模板，要么改正新文件创build后的命名空间。
在Visual Studio中，我也感受到这种“默认”行为的痛苦。
当您将LinqToSql .dbml文件放在自己的目录中时，Visual Studio也尝试设置命名空间/目录匹配。 每当我编辑.dbml ，我必须记住：
- 打开
.dbml.designer.cs文件 - 从
namespace声明中删除目录/文件夹名称
但是，有一种方法可以阻止这种行为 。 它涉及到创build一个自定义类模板。
我认为有确实的理由有不同的名称空间和项目文件夹的结构。 如果你正在开发一个库，那么这个名字空间结构应该首先为你的API的用户提供服务：它应该是合乎逻辑的，易于掌握。 另一方面，文件夹结构应该主要是为了让您的devise人员轻松生活。 有些目标确实非常相似，就像这个结构也是合乎逻辑的。 但也可能有不同的，例如，您可以快速select相关的文件进行工具，或者很容易导航。 我自己例如往往创build新的文件夹，当达到某个文件的阈值，否则只需要太长时间来find我正在寻找的文件。 但是尊重devise者的偏好也意味着严格遵循命名空间 – 如果这是他们的偏好。
总的来说，在很多情况下，两者都是合理的，但是我认为有些情况是有偏差的。
过去对我有帮助的是在一个地方创build一个文件（例如WPF UserControl）来获得命名空间，然后将其移动到“右”文件夹。
虽然我同意将名称空间层次结构与文件夹层次结构匹配是方便的，但是我认为Visual Studio似乎不支持将此functionclosures的事实令人厌恶。 Visual Studio有很多应用程序，并且有很多编码风格和构build源文件文件夹的方式非常好。
假设有数以千计的属于命名空间的文件，但程序员只是想将它们分组到文件夹中，以使层次结构更易于导航。 这真的是一个坏主意吗？ 这是否真的使事情如此不可维护，它应该被禁止的IDE？
假设我正在使用Visual Studio来处理Unity。 现在，我所有的脚本都在“Assets.Scripts”命名空间中。 不仅有一个无用的Assets命名空间，现在不包含任何脚本，但“Assets.Scripts”没有意义 – 它没有描述源文件属于哪个项目或部分项目。 无用。
