3

我记得读过一次（我相信这本书是 .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等访问功能。

就好像有一条潜规则规定，当涉及到命名空间时，“你对自己的孩子一无所知，但你可以知道关于你的祖父母、阿姨、叔叔、侄女的孩子的一切，侄子和堂兄弟。” 这条准则对我来说似乎违反直觉且毫无意义。它似乎使命名空间设计复杂化。

所以这是问题

您如何在自己的大型应用程序中设计命名空间？您真的关心保留命名空间边界吗？如果是这样，您如何解决类明确相关的问题（尽管已经尽可能多地解耦）？

我对您的经历以及您对此的意见非常感兴趣。它已经困扰我一段时间了。如果您可以为包含业务对象、数据实体等的 3 层应用程序提供命名空间安排的示例，那就太好了。我真的很想看看你们是如何获得命名空间模型的，以及为什么。

首先十分感谢！

4

1 回答 1

3

如果您有两个紧密相关的类，您只需将它们放在同一个命名空间中。

我认为命名空间用于保存相关的类、函数、枚举等，所以这应该很自然。

Now it might be the case that some namespaces naturally build on items in other namespaces. But if two classes are so closely related as to build on each other, I'm not sure why I would even consider putting them in different namespaces. There's probably a good reason, but I've never come across it.

于 2008-12-23T18:50:00.570 回答