我记得曾经读过一次（我相信这本书是.NET Framework设计指南），当你设计一个框架或类库时，你应该注意如何在命名空间中安排类。具体来说，父命名空间中的类应该不了解子命名空间中的类。相反，子命名空间中的类完全可以了解它们上面的命名空间中的类。
例如， System 命名空间中的类对 System.Data.SqlClient 命名空间中的类一无所知。但是， System.Data.SqlClient 中的类知道系统和 System.Data 中的类。
现在，从表面上看，这是一个非常直接的想法。但有时候这并不像你想象的那么容易实现。类本质上本质上是相互耦合的。例如：
当然，您可以将它们分成单独的，离散的类，清楚地隔离数据和功能;那不是我的问题。我的问题是如何正确地将它们安排到观察名称空间的最佳实践的命名空间中。
这对我来说似乎总是有点模糊。我从来没有看到它清楚地解决，我见过的大多数样本只是将数据对象放在根命名空间（MyProject.DataObjects）或类似的东西。就好像没有人确定，所以我们不要谈论它。
我可以看到，在.NET Framework本身中，类始终跨命名空间边界访问所需的功能。课程经常从 System.Collections ， System.Collections.Generic ， System.Runtime ， System.Configuration 访问功能， System.Reflection ，依此类推。
就好像有一条潜规则说明，当涉及名称空间时，“你对自己的孩子一无所知，但你可以知道所有关于你的祖父母，阿姨的孩子，叔叔，尼思，侄子和表兄弟。“这条准则对我来说似乎是违反直觉和毫无意义的;它似乎使名称空间设计复杂化。
所以这是问题
如何在自己的大型应用程序中设计命名空间？你是否真的关心保留命名空间边界？如果是这样，你如何解决课程明显相关的问题（尽管你已经尽可能多地解耦）？
我真的对你的经历以及你对此的看法感兴趣。这一直困扰着我一段时间。如果您可以为包含业务对象，数据实体等的3层应用程序提供命名空间排列示例，那就太棒了。我真的很想看看你们是如何到达命名空间模型的，以及为什么。
非常感谢！
答案 0 :(得分：3)
如果你有两个紧密相关的类，你只需将它们放在同一个命名空间中。
我认为命名空间是用于保存相关的类，函数，枚举等，所以这应该是很自然的。
现在情况可能是某些名称空间自然地构建在其他名称空间中的项目上。但是，如果两个类彼此密切相关，那么我不确定为什么我会考虑将它们放在不同的名称空间中。这可能是一个很好的理由，但我从未遇到过它。