我记得曾经阅读过一本书（我相信这本书是.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等地方访问功能。
这似乎有一条不成文的规定，即在命名空间方面，“你不能知道自己的子级，但是你可以了解祖父母、姑姑、叔叔、侄女、侄子和表兄弟姐妹的所有信息。”这个指南对我来说似乎是违反直觉和无意义的；它似乎使命名空间设计变得更加复杂。
所以问题来了：
- 在您自己的大型应用程序中，您如何设计命名空间？ - 您是否真的很关心保留命名空间边界？如果是这样，您如何解决明显相关的类的问题（尽管已经尽可能地减少了耦合）？
我真的很感兴趣听取您的经验和意见。这件事困扰了我一段时间了。如果您能提供一个包括业务对象、数据实体等的三层应用程序的命名空间安排示例，那就太好了。我真的很想看看您是如何到达您的命名空间模型的，以及为什么。
非常感谢您提前的帮助！
例如，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等地方访问功能。
这似乎有一条不成文的规定，即在命名空间方面，“你不能知道自己的子级，但是你可以了解祖父母、姑姑、叔叔、侄女、侄子和表兄弟姐妹的所有信息。”这个指南对我来说似乎是违反直觉和无意义的；它似乎使命名空间设计变得更加复杂。
所以问题来了：
- 在您自己的大型应用程序中，您如何设计命名空间？ - 您是否真的很关心保留命名空间边界？如果是这样，您如何解决明显相关的类的问题（尽管已经尽可能地减少了耦合）？
我真的很感兴趣听取您的经验和意见。这件事困扰了我一段时间了。如果您能提供一个包括业务对象、数据实体等的三层应用程序的命名空间安排示例，那就太好了。我真的很想看看您是如何到达您的命名空间模型的，以及为什么。
非常感谢您提前的帮助！