我最近将正在进行的解决方案从24个项目重组为4个。
要将大量文件保存在“主”项目中，事情就在文件夹中的文件夹中。我认为我保留了解决方案内容的逻辑，可发现的安排。
因此，当然，我最终会使用 AppName.DataAccess.NHibernate.Fluent.Mappings这样的名称空间。
当我的项目有一个有点深层嵌套的文件夹结构时，是否有任何令人信服的理由说我应该关注命名空间层次结构？
（我不关心解析或管理 using 指令;我让ReSharper在这里完成所有繁重工作。）
答案 0 :(得分：4)
我只会在有明显维护优势的地方展平。
命名空间更多用于组织目的，还有助于减少命名冲突。我倾向于使我的命名空间与.NET Framework和其他主要库命名空间保持一致。这有助于其他人更容易地找到课程。 （正如你所说，可发现的安排。）例如，我的路径实用程序在Missico.IO.Path下，我的数据访问库在Missico.Data下，我的应用程序在AppName.DataManager下的数据访问（使用Missico.Data和所有其他数据）命名空间）。
我总是在根命名空间使用我的姓氏或公司名称。 （任何名词都可以。）这允许用户（程序员）通过源代码中的简单名称更改或库引用的使用别名轻松解决命名冲突。
using Company = Missico;
String x = Company.IO.Path.CommonPath("", "");
我尝试为每个命名空间保留一个文件夹。如果命名空间是嵌套的，则嵌套文件夹。这有助于我和其他人更快地找到源代码，因为他们熟悉命名空间结构。为什么要让他们学习两种结构。每个文件夹都包含该命名空间的所有源文件，复杂类除外。他们得到了自己的子文件夹（没有更改名称空间。）我最终可能会得到一个名称空间文件夹，其中包含四个或五个子文件夹，用于复杂类和支持类。
请注意，由于定义System命名空间会导致各种麻烦，因此我将Core用作我的“系统/全局”命名空间。
答案 1 :(得分：0)
我一直都在考虑在有意义的命名空间名称中保留小的可重用类。所以我的答案是否定的，不要试图缩小命名空间层次结构。