我记得曾经读过一次(我相信那本书是 .NET Framework 设计指南)，当您设计一个框架或类库时，您应该注意如何在您的命名空间中安排类。具体来说，父命名空间中的类应该不知道子命名空间中的类。相反，子命名空间中的类知道其上方命名空间中的类是完全可以的。
例如，System 命名空间中的类对System.Data.SqlClient 命名空间中的类一无所知。但是，System.Data.SqlClient 中的类知道 System 和 System.Data 中的类。
现在，从表面上看，这是一个非常简单的想法。但在某些情况下，这并不像您想象的那么容易实现。类本质上是相互耦合的。例如:
- 商务舱
- 数据实体类
- 将数据实体类映射到业务对象类的类
- 序列化数据实体进出数据库的类
当然，您可以将它们分成单独的离散类，这些类清楚地隔离数据和功能；那不是我的问题。我的问题是如何将它们正确地安排到遵守命名空间最佳实践的命名空间中。
这对我来说总是有点模糊。我从来没有看到它被清楚地解决了，而且我见过的大多数示例只是将数据对象放在根命名空间 (MyProject.DataObjects) 或类似的东西之外。好像没有人真正确定，所以我们只是不谈论它。
我可以看到，在 .NET Framework 本身中，类总是跨越命名空间边界来访问它们需要的功能。类经常访问来自 System.Collections、System.Collections.Generic、System.Runtime、System.Configuration 的功能、System.Reflection 等。
就好像有一个潜规则说的那样，当涉及到命名空间时，“你不能知道关于你自己的 child 的任何事情，但你可以知道所有关于你祖 parent 、阿姨、叔叔、侄女、侄子和堂 sibling 。”这条准则对我来说似乎违反直觉且毫无意义；它似乎使 namespace 设计复杂化。
问题来了
您如何在自己的大型应用程序中设计 namespace ？您真的很关心保留 namespace 边界吗？如果是这样，您如何解决类明显相关的问题(尽管已尽可能多地解耦)？
我真的很想知道您的经历，以及您对此的意见。它已经困扰我一段时间了。如果您能为包含业务对象、数据实体等的 3 层应用程序提供命名空间安排的示例，那就太好了。我真的很想看看你们是如何得出命名空间模型的，为什么。
非常感谢!
最佳答案
如果您有两个紧密相关的类，只需将它们放在同一个命名空间中即可。
我认为命名空间是用来保存相关类、函数、枚举等的，所以这应该是很自然的。
现在可能是某些命名空间自然地构建在其他命名空间中的项目之上的情况。但是，如果两个类密切相关以致于相互构建，我不确定为什么我什至会考虑将它们放在不同的 namespace 中。可能有一个很好的理由，但我从未遇到过。
关于namespaces - 命名空间设计和类意识，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/389714/