我最近将正在进行的解决方案从24个项目重组为4个。
为了使大量文件保持在“主”项目中，文件位于文件夹中的文件夹中。我认为我保留了解决方案内容的合理，可发现的安排。
结果，我最终得到了AppName.DataAccess.NHibernate.Fluent.Mappings之类的命名空间。
当我的项目具有某种深度嵌套的文件夹结构时，是否有任何令人信服的理由值得我关注展平命名空间层次结构？
（我不关心解析或管理using指令；我让ReSharper在这里完成所有繁重的工作。）
最佳答案
我只会在有明显维护优势的地方进行展平。
命名空间更多地用于组织目的，并具有帮助减少命名冲突的额外好处。我倾向于使我的名称空间与.NET Framework和其他主要库名称空间保持一致。这有助于其他人更轻松地查找课程。 （如您所说，这是可发现的安排。）例如，我的路径实用程序在Missico.IO.Path下，我的数据访问库在Missico.Data下，我的应用程序数据访问在AppName.DataManager下（它使用Missico.Data和所有其他数据）命名空间）。
我总是在根名称空间中使用我的姓氏或公司名称。 （任何名词都可以。）这使用户（程序员）可以通过简单地在源代码中更改名称或为库引用使用别名来轻松解决命名冲突。
using Company = Missico;
String x = Company.IO.Path.CommonPath("", "");
我尝试为每个名称空间保留一个文件夹。如果命名空间是嵌套的，则嵌套文件夹。这有助于我和其他人更快地找到源代码，因为他们熟悉名称空间结构。为什么要让他们学习两种结构。每个文件夹包含该名称空间的所有源文件，复杂类除外。他们到达那里自己的子文件夹（不更改名称空间）。我可能最终得到一个名称空间文件夹，其中包含用于复杂类和支持类的四个或五个子文件夹。
请注意，由于定义系统名称空间会引起各种麻烦，因此我将Core用作“系统/全局”名称空间。
关于c# - 我应该担心统治 namespace 编号/长度/范围吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2563321/