Java23种设计模式（五）
1、MVC 模式
MVC 模式代表 Model-View-Controller（模型-视图-控制器） 模式。这种模式用于应用程序的分层开发。
Model（模型） - 模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器。
View（视图） - 视图代表模型包含的数据的可视化。
Controller（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。
1.1、实现方式
- 模型（Model）：负责数据和业务逻辑，通常包含数据存储、检索和业务规则。
- 视图（View）：负责显示数据（模型）的用户界面，不包含业务逻辑。
- 控制器（Controller）：接收用户的输入，调用模型和视图去完成用户的请求。
当开发大型应用程序，需要清晰分离数据、业务逻辑和用户界面时，考虑使用MVC模式。
2、业务代表模式
业务代表模式（Business Delegate Pattern）用于对表示层和业务层解耦。它基本上是用来减少通信或对表示层代码中的业务层代码的远程查询功能。在业务层中我们有以下实体。
- 客户端（Client） - 表示层代码可以是 JSP、servlet 或 UI java 代码。
- 业务代表（Business Delegate） - 一个为客户端实体提供的入口类，它提供了对业务服务方法的访问。
- 查询服务（LookUp Service） - 查找服务对象负责获取相关的业务实现，并提供业务对象对业务代表对象的访问。
- 业务服务（Business Service） - 业务服务接口。实现了该业务服务的实体类，提供了实际的业务实现逻辑。
Web应用程序：Web层作为表示层，通过业务代表访问后端服务层。
3、组合实体模式
组合实体模式（Composite Entity Pattern）用在 EJB 持久化机制中。一个组合实体是一个 EJB 实体 bean，代表了对象的图解。当更新一个组合实体时，内部依赖对象 beans 会自动更新，因为它们是由 EJB 实体 bean 管理的。以下是组合实体 bean 的参与者。
- 组合实体（Composite Entity） - 它是主要的实体 bean。它可以是粗粒的，或者可以包含一个粗粒度对象，用于持续生命周期。
- 粗粒度对象（Coarse-Grained Object） - 该对象包含依赖对象。它有自己的生命周期，也能管理依赖对象的生命周期。
- 依赖对象（Dependent Object） - 依赖对象是一个持续生命周期依赖于粗粒度对象的对象。
- 策略（Strategies） - 策略表示如何实现组合实体。
将数据库中的表转换为应用程序中的组合对象，这些对象可以表示表中的单个记录或一组记录。
解决在对象关系映射中，如何高效地表示和管理数据库中的复杂数据结构，特别是当存在一对多或多对多关系时。
4、数据访问对象模式
数据访问对象模式（Data Access Object Pattern）或 DAO 模式用于把低级的数据访问 API 或操作从高级的业务服务中分离出来。以下是数据访问对象模式的参与者。
- 数据访问对象接口（Data Access Object Interface） - 该接口定义了在一个模型对象上要执行的标准操作。
- 数据访问对象实体类（Data Access Object concrete class） -
该类实现了上述的接口。该类负责从数据源获取数据，数据源可以是数据库，也可以是 xml，或者是其他的存储机制。
- 模型对象/数值对象（Model Object/Value Object） - 该对象是简单的 POJO，包含了 get/set
方法来存储通过使用 DAO 类检索到的数据。
将数据访问逻辑从业务逻辑中分离出来，并将数据访问操作封装在一个专用的类中。
4.1、实现方式
- 定义DAO接口：声明数据访问操作的方法。
- 实现DAO类：实现DAO接口，封装对数据源（如数据库）的所有访问逻辑。
- 数据传输对象（DTO）：可选，用于封装从数据源检索的数据。
4.2、包含的几个主要角色
- DAO接口（DAO Interface）：声明数据访问和操作的方法。
- DAO实现（DAO Implementation）：实现DAO接口，封装对数据源的所有访问逻辑。
- 数据传输对象（Data Transfer Object,
DTO）（可选）：封装从数据源检索的数据，用于业务逻辑层与数据访问层之间的数据传输。
- 业务逻辑层（Business Logic Layer）：使用DAO接口与数据源交互，不直接依赖于数据访问的具体实现。
- 数据源（Data Source）：数据库或其他持久化存储，DAO实现与之交互以存取数据。
数据访问对象模式通过提供一个清晰的数据访问层，有助于保持应用程序的整洁和可管理性。
5、前端控制器模式
前端控制器模式（Front Controller Pattern）是用来提供一个集中的请求处理机制，所有的请求都将由一个单一的处理程序处理。该处理程序可以做认证/授权/记录日志，或者跟踪请求，然后把请求传给相应的处理程序。以下是这种设计模式的实体。
- 前端控制器（Front Controller） - 处理应用程序所有类型请求的单个处理程序，应用程序可以是基于 web的应用程序，也可以是基于桌面的应用程序。
- 调度器（Dispatcher） - 前端控制器可能使用一个调度器对象来调度请求到相应的具体处理程序。
- 视图（View） - 视图是为请求而创建的对象。
解决Web应用程序中请求处理分散的问题，提供统一的请求处理入口。
6、拦截过滤器模式
拦截过滤器模式（Intercepting Filter Pattern）用于对应用程序的请求或响应做一些预处理/后处理。定义过滤器，并在把请求传给实际目标应用程序之前应用在请求上。过滤器可以做认证/授权/记录日志，或者跟踪请求，然后把请求传给相应的处理程序。以下是这种设计模式的实体。
- 过滤器（Filter） - 过滤器在请求处理程序执行请求之前或之后，执行某些任务。
- 过滤器链（Filter Chain） - 过滤器链带有多个过滤器，并在 Target 上按照定义的顺序执行这些过滤器。 Target -
Target 对象是请求处理程序。
- 过滤管理器（Filter Manager） - 过滤管理器管理过滤器和过滤器链。
- 客户端（Client） - Client 是向 Target 对象发送请求的对象。
用于在请求到达最终目的地之前，通过一系列过滤器对请求进行预处理和后处理。
7、服务定位器模式
服务定位器模式（Service Locator Pattern）用在我们想使用 JNDI 查询定位各种服务的时候。考虑到为某个服务查找 JNDI 的代价很高，服务定位器模式充分利用了缓存技术。在首次请求某个服务时，服务定位器在 JNDI 中查找服务，并缓存该服务对象。当再次请求相同的服务时，服务定位器会在它的缓存中查找，这样可以在很大程度上提高应用程序的性能。以下是这种设计模式的实体。
- 服务（Service） - 实际处理请求的服务。对这种服务的引用可以在 JNDI 服务器中查找到。
- Context / 初始的 Context - JNDI Context 带有对要查找的服务的引用。
- 服务定位器（Service Locator） - 服务定位器是通过 JNDI 查找和缓存服务来获取服务的单点接触。
- 缓存（Cache） - 缓存存储服务的引用，以便复用它们。
- 客户端（Client） - Client 是通过 ServiceLocator 调用服务的对象。
用于在应用程序中提供一个中心化的服务访问点，用以获取各种服务或资源。
8、传输对象模式
传输对象模式（Transfer Object Pattern）用于从客户端向服务器一次性传递带有多个属性的数据。传输对象也被称为数值对象。传输对象是一个具有 getter/setter 方法的简单的 POJO 类，它是可序列化的，所以它可以通过网络传输。它没有任何的行为。服务器端的业务类通常从数据库读取数据，然后填充 POJO，并把它发送到客户端或按值传递它。对于客户端，传输对象是只读的。客户端可以创建自己的传输对象，并把它传递给服务器，以便一次性更新数据库中的数值。以下是这种设计模式的实体。
- 业务对象（Business Object） - 为传输对象填充数据的业务服务。
- 传输对象（Transfer Object） - 简单的 POJO，只有设置/获取属性的方法。
- 客户端（Client） - 客户端可以发送请求或者发送传输对象到业务对象。
用于简化网络或应用程序层之间的数据传输。它通过创建一个包含多个属性的类来封装数据，这些属性代表需要传输的数据。
主要解决的问题
解决在分布式系统中，尤其是多层应用程序中，数据在层与层之间传输时的效率和封装性问题。
使用场景
