Question

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

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

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

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

Answer 1

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

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

Answer 2

我建议您阅读Types and Namespaces的Design Guidelines for Developing Class Libraries页面。详细说明何时应使用名称空间，并提供一般指导。

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

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

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

命名空间 - 逻辑分组类

2 个答案: