我应该停止对抗Visual Studio的默认命名空间命名约定吗？

Question

我正在开发一个MVVM项目,所以我的项目中有像Models,ViewModels,Windows等文件夹.每当我创建一个新类时,Visual Studio会自动将文件夹名称添加到命名空间名称而不是仅保留项目 - 级别命名空间 因此,向ViewModels文件夹添加一个新类将导致命名空间,MyProject.ViewModels而不仅仅是MyProject.

当我第一次遇到这个时,它让我恼火.我的类名很清楚,有时甚至包含其中的文件夹名称(例如ContactViewModel).我很快发现自己手动删除名称空间上的文件夹名称.我甚至试图创建一个自定义类模板(请参阅此问题),但我无法使其工作,因此继续手动执行.

不过,我开始怀疑,如果这个惯例存在的原因是我没有看到的.如果你出于某种原因将许多相同的类名组织成文件夹,我可以看到它很有用,但这似乎不是特别常见的情况.

问题:

• 为什么命名空间名称的常见约定反映文件夹结构？
• 你遵守这个惯例吗？为什么？

Answer 1

和你一样 - 我打了最长时间.然后我开始考虑为什么我创建了文件夹.我发现自己开始创建文件夹来表示命名空间和包而不是任意存储桶.

例如,在MVVM项目中,将视图和视图模型放在单独的命名空间中可能会有所帮助.MVC将为模型,控制器和视图提供单独的命名空间.通过其功能对类进行分组也是有益的.

突然间,该项目感觉更有条理.其他开发人员更容易找到功能的实现位置.

如果您对命名空间实践进行标准化,那么您的所有项目都将具有相同的可预测结构,这将是维护的一大胜利.

Answer 2

如果您需要一些可靠的建议,我建议您购买框架设计指南:可重用.NET库的约定,惯用法和模式,它们为您提供实际框架设计团队所需要的所有知识.

...命名命名空间的目标是为程序员创建足够的清晰度,使用框架立即知道命名空间的内容可能是什么......

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

而且重要的是

不要对命名空间使用相同的名称,也不要在该命名空间中使用类型

将每1/2个类型分段为命名空间将不符合第一个要求,因为如果您遵循Visual Studio方式,您将需要限定或使用名称空间的沼泽.例如

核心 - 域 - 用户 - 权限 - 帐户

你会创造吗？

• MyCompany.Core.Domain.Users
• MyCompany.Core.Domain.Permissions
• MyCompany.Core.Domain.Accounts

要不就

• MyCompany.Core.Domain

对于Visual Studio来说,它将是前者.此外,如果您使用小写文件/文件夹命名,则每次都要重命名该类,以及使一个大的命名空间纠结.

如果您是自己的API或框架的消费者,那么大多数是常识,并且真正取决于您期望如何组织命名空间.

Answer 3

我对此感到恼火,但是使用大型代码库进行工作和重构项目很快就教会了我.接受了这个概念后,我认为这是一种非常好的方式来"物理"和逻辑地构建代码.当您有一个大型项目并且命名空间与文件夹不匹配时,很难快速找到文件.还有更难以记住事情的地方......

此外,如果ReSharper推荐它,那么这可能是一个好主意.例如,如果您的类的命名空间与其文件夹名称不匹配,R#将会抱怨.

Answer 4

文件系统文件夹和命名空间都代表层次结构.我似乎很自然地匹配这两者.我甚至更进一步,在文件和类之间使用1:1的关系.当我使用其他语言(如C++)编程时,我甚至会这样做.

现在你质疑这两个层次结构之间的关系,我真的很想知道你希望文件系统层次结构代表什么.

Answer 5

不遵循约定的一种方法是在项目根文件夹中创建文件,然后将其移动到最终的子文件夹.

无论如何,这是我真正喜欢的惯例.如果我将类型拆分为文件夹,则可能这些类型具有与该文件夹相关的某种概念分组.因此,它结束了一些意义,它们的命名空间也类似.Java采用这种方法并使用其包系统强制执行它.最大的区别是VS只是"向你建议",因为语言或CLR都没有强制执行它.

Answer 6

虽然我同意其他人的观点，即匹配逻辑结构的物理结构是有帮助的，但我不得不说我也与 Visual Studio 的自动命名作斗争。我必须重命名类的原因有六个：

• 我使用根“src”文件夹在视觉上将我的代码与嵌入的资源分开
• 我想要不同的大小写
• 我会将我的代码组织到子文件夹中，以便在命名空间内进行组织
• 我喜欢将接口与实现和基类分开
• 我觉得像

出于种种原因，我已经让自己不得不为我创建的每个类调整这些。我避免这个问题的策略是复制一个具有我想要的命名空间声明的文件，然后立即删除内容。

Answer 7

我认为命名空间和项目文件夹具有不同的结构确实有充分的理由。如果您正在开发一个库，那么命名空间结构首先应该为您的 API用户服务：它应该符合逻辑且易于掌握。另一方面，文件夹结构的主要目的应该是让API 设计者的生活变得轻松。有些目标确实非常相似，比如结构也应该符合逻辑。但也可能有不同的，例如您可以快速选择相关文件进行工具，或者易于导航。例如，我自己倾向于在达到某个文件阈值时创建新文件夹，否则需要很长时间才能找到我正在查找的文件。但尊重设计师的偏好也意味着严格遵循命名空间——如果这是他们的偏好的话。

总的来说，在很多情况下，两者匹配是有道理的，但我认为也有一些有效的情况可以偏离。

过去对我有用的是在一个地方创建一个文件（例如 WPF UserControl）以获得正确的命名空间，然后将其移动到“正确”的文件夹。