c# - 我应该担心命名空间编号/长度/范围的统治吗？

Question

我最近将一个正在进行的解决方案从 24 个项目重组为 4 个。

为了让“主”项目中的大量文件井井有条，所有东西都在文件夹中的文件夹中。我认为我保留了解决方案内容的逻辑、可发现的安排。

因此，当然，我最终得到了类似 AppName.DataAccess.NHibernate.Fluent.Mappings 的命名空间。

当我的项目具有嵌套较深的文件夹结构时，是否有任何令人信服的理由表明我应该关心展平命名空间层次结构？

(我不关心解决或管理 使用 指令；我让 ReSharper 在这里完成所有繁重的工作。)

Answer 1

我只会在有明显维护优势的地方展平。

命名空间更多地用于组织目的，还有有助于减少命名冲突的额外好处。我倾向于使我的命名空间与 .NET Framework 和其他主要库命名空间保持一致。这有助于其他人更轻松地找到类(class)。 (正如你所说，可发现的安排。)例如，我的路径实用程序在 Missico.IO.Path 下，我的数据访问库在 Missico.Data 下，我的应用程序的数据访问在 AppName.DataManager 下(它使用 Missico.Data 和所有其他数据命名空间)。

我总是在根命名空间中使用我的姓氏或公司名称。 (任何名词都可以。)这允许用户(程序员)通过在源代码中进行简单的名称更改或使用库引用的别名来轻松解决命名冲突。

using Company = Missico;
String x = Company.IO.Path.CommonPath("", "");

我尝试为每个命名空间保留一个文件夹。如果命名空间是嵌套的，则嵌套文件夹。这有助于我和其他人更快地找到源代码，因为他们熟悉命名空间结构。为什么要让他们学习两种结构。每个文件夹都包含该命名空间的所有源文件，复杂类除外。他们获得了自己的子文件夹(不更改命名空间。)我最终可能会得到一个命名空间文件夹，其中包含用于复杂类和支持类的四个或五个子文件夹。

请注意，由于定义系统命名空间会导致各种麻烦，因此我使用 Core 作为我的“系统/全局”命名空间。