2

我了解如何对类进行物理分组，即继承、组合等。但是，我从未真正理解命名空间的好处（类的逻辑分组）。我通常有一个表示层的名称空间，一个业务逻辑层的名称空间和一个数据访问层的名称空间，即：

com.Application.BusinessLogicLayer  
com.Application.PresentationLayer
com.Application.DataAccessLayer

有时表示层会有多个应用程序，例如 VB.NET 应用程序和 ASP.NET 应用程序。有时业务逻辑层会被拆分为多个 DLL。

我可以回答关于什么是命名空间的考试问题，但我很难将知识应用到问题领域。例如，看看下面的代码：

Namespace com.application.businesslogiclayer
    Public Class ClassA
        Private CB As ClassB
    End Class
End Namespace
Namespace com.application.businesslogiclayer
    Public Class ClassB
        Private CC As ClassC
    End Class
End Namespace

Namespace com.application.businesslogiclayer
    Public Class ClassC

    End Class
End Namespace

由于 ClassA 与 ClassB 有组合关系，而 ClassB 与 ClassC 有组合关系，所以我相信它们都应该属于同一个命名空间，例如

com.application.businesslogiclayer.classABC

. 但是，您可以使用“导入”语句引入其他类，所以这可能是不正确的。

开发人员在设计命名空间时使用什么标准？

4

2 回答 2

4

命名空间不仅可用于对类型进行逻辑分组，还可用于避免类型之间的命名冲突，因为命名空间也是完整类型名称的一部分。例如，您的应用程序中可能有一个名为 Log 的类，但您还引用了由其他人编写的另一个程序集，该程序集也有一个名为 Log 的类。在某些实现中使用这两个 Log 类可能有一个实际的原因（即因为它们执行不同类型的日志记录，或者一个用于记录信息，另一个表示树的一部分）并且命名空间允许编译器区分这两个 Log类。不要低估使用命名空间进行分组的有用性，因为这在大型项目中变得更加重要。

就标准而言，从单个命名空间开始。随着应用程序的发展，您可能希望使用两个或多个嵌套命名空间来整理单个命名空间，以更好地组织代码，也许要折叠一些您当前不在 IDE 中处理的代码以使其不碍事，但分组应该合乎逻辑且有意义。在 .NET 中，请遵循基类库中命名空间的设计指南和示例。

于 2013-02-15T18:46:41.720 回答
2

我建议阅读类库开发设计指南的类型和命名空间页面。这详细说明了何时应使用命名空间，并提供一般指导。

通常，将您的类型组织到单独的命名空间中，其中相关的功能被分组到一个命名空间中，这有助于保持您的项目井井有条。

在您的情况下，您可能希望将所有主要业务逻辑放入一个命名空间，但将您的表示逻辑分离到它自己的命名空间中。这在很多方面都有帮助，包括允许编译器帮助防止您混淆关注点（如果不显式添加 Import 语句，您不能使用错误的类）。

这也有助于避免类型名称冲突，因此您可以在每个问题区域内使用简单、干净、易于理解的名称。

于 2013-02-15T18:51:30.030 回答