4、Spring 应用架构解析

Spring 应用架构解析

1. Spring 架构概述

Spring 旨在实现架构的灵活性。例如，若要从 Hibernate 切换至 JDO，或者反之，又或者切换到即将推出的 JSR - 220 POJO 持久化 API，使用 Spring 并遵循推荐实践会让这一过程更为轻松。同样，对于是否使用 EJB 实现某一功能，你可以延迟做出选择，并且确信若最终由 EJB 而非 POJO 实现特定服务，也无需修改现有代码。

典型的 Spring 应用架构从下至上各层及其职责如下：
| 层次 | 职责 |
| — | — |
| 表示层 | 通常为 Web 层，应尽可能轻薄。可在设计良好的中间层上有多种替代表示层，如 Web 层或远程 Web 服务门面。 |
| 业务服务层 | 负责事务边界，为系统整体操作提供入口点。该层不应了解表示层的问题，且应可复用。 |
| DAO 接口层 | 是独立于任何数据访问技术的接口层，用于查找和持久化持久对象。该层实际上是业务服务层的策略接口，不应包含业务逻辑。接口实现通常使用 O/R 映射技术或 Spring 的 JDBC 抽象。 |
| 持久域对象 | 对真实对象或概念进行建模，如银行账户对象。 |
| 数据库和遗留系统 | 最常见的是单个关系数据库管理系统（RDBMS），但也可能有多个数据库，或数据库与其他事务性或非事务性遗留系统或企业资源的混合。这通常被称为企业信息系统（EIS）层。 |

在 J2EE 应用中，除 EIS 层外的所有层都将在应用服务器或 Web 容器中运行。域对象通常会传递到表示层，该层将显示其包含的数据，但不修改它们，修改仅在业务服务层定义的事务边界内进行。因此