三层架构中表现层与数据层的隔离问题-CSDN博客

一、数据层对表现层不可见

在三层架构（表现层、业务逻辑层、数据访问层）中，理想情况下，表现层应该对数据访问层（数据层）的数据结构定义是不可见的。这种设计有助于实现关注点分离（Separation of Concerns, SoC），使得各层之间保持松散耦合，从而提高系统的可维护性和可扩展性。

表现层：主要负责与用户交互，显示信息和接收用户输入。它不应该直接访问数据层，而是通过调用业务逻辑层提供的接口来获取或提交数据。
业务逻辑层：处理业务规则和逻辑，它调用数据访问层来获取或存储数据，并根据业务需求对数据进行处理。业务逻辑层对数据层的数据结构是可见的，因为它需要知道如何操作这些数据。
数据访问层：直接与数据库或其他数据源交互，处理数据的存储和检索。它封装了数据访问的细节，如SQL查询、数据库连接等。

在三层架构中，数据访问层的具体实现和数据结构对业务逻辑层是可见的，但对表现层应该是隐藏的。表现层应该只关心数据的表示和用户的交互，而不关心数据的具体存储方式和结构。这样，如果底层数据结构发生变化，只需要修改数据访问层和可能受影响的业务逻辑层代码，而无需修改表现层代码。

为了实现这一设计原则，通常会定义一些数据传输对象（Data Transfer Objects, DTOs）或视图模型（View Models）来在层与层之间传递数据。这些对象通常只包含表现层需要显示的数据，而不暴露底层数据的具体结构。

二、数据传输对象（DTOs）简化数据的跨层穿越

数据传输对象（DTOs，Data Transfer Objects）是在软件系统中用于在不同层或组件之间传输数据的对象。它们主要用于封装数据，以便在应用程序的不同部分之间进行有效和安全的数据交换。以下是关于DTOs的详细介绍：

定义和用途：
- DTOs是简单的Java类（通常称为POJOs，即Plain Old Java Objects），它们不包含任何业务逻辑，只用于数据的存储和传输。
- DTOs的主要目的是在不同软件层之间传递数据，特别是在远程调用或分布式系统中，以减少通过网络发送的数据量。
设计原则：
- 封装性：DTOs通过公共的setter和getter方法提供对其属性的访问，隐藏内部数据结构。
- 数据正交性：DTO应仅包含传输所需的数据，避免设计过度。
- 层间隔离：DTOs的设计应独立于特定的业务逻辑或数据库结构，以便于在不同层间传输数据。
在软件架构中的应用：
- 在典型的三层架构中（表示层、服务层、数据访问层），DTOs主要在表示层与服务层之间，以及服务层与数据访问层之间传递数据。
- 例如，在一个电子商务系统中，用户的订单信息可以通过一个OrderDTO从前端传递到后端进行处理。
优势与挑战：
- 优势：DTOs可以减少数据传输的成本，提高数据安全性（通过数据过滤和校验），并为系统间的数据交互提供抽象层，简化不同层之间的数据依赖。
- 挑战：过度使用DTOs可能导致类数量增加，从而增加系统的复杂度。同时，随着系统的演化，DTOs的维护可能会变得复杂。
与其他模式的比较：与直接使用领域模型对象进行数据传输相比，DTOs更注重数据的传输而不是领域逻辑。这有助于避免将领域对象的行为暴露给表现层或其他非业务逻辑层。