Spring构建应用系统的最佳架构与模式实践（1）

蔡 超

SCEA，SCBCD，MCSD，IBM RUP Specilist

北京天融信软件架构师

SUN,Microsoft培训中心特邀高端教师

常年提供架构咨询服务

chaocai2001@yahoo.com.cn ，010-82776427

 

引言

在使用Spring构建应用时和采用EJB构建应用一样同样也存在不少常用模式和最佳实践，当然很多Core J2EE Pattern仍然是我们构建spring应用中的优秀模式，不过有的也不再适用了（如：IoC的应用使得Service Locator不再适用，Hibernate取代Entity Bean使得DTO不再适用等）。

下文是一些在以Spring为核心的架构中的常见模式和架构最佳实践。

 

图表 1 Spring应用常见架构模式列表

DAO模式

虽然采用了诸如Hibernate这样的O/R Mapping工具或是iBates这样的SQL Mapping工具但是采用DAO模式仍有相当好处。

在实际应用中我们常会遇到如下问题：

1 性能问题：由于性能问题我们可能要改变数据访问方式，如采用JDBC替换Hibernate这时，这时如果采用了DAO模式，数据访问被有效的封装和业务逻辑完全分离，易于实现替换。

2 移植问题：需要支持多种数据库，DAO模式仍然是一种稳妥的选择。虽然诸如Hibernate及iBates也提供很好的数据库无关性，但如果使用某些数据库的特殊功能时，就会出现问题。

当然，对于是否采用DAO模式也不可一概而论，应为他毕竟会增加应用的开发复杂性。个人认为很关键的一个判定条件是业务逻辑是否会和持久化逻辑混合。

 

Application Service模式

封装一定的业务逻辑和功能，提高复用性，即防止Façade和业务对象的臃肿。注意在此可以应用Command模式及Strategy模式提供系统可维护性和可扩展性。

这个模式很重要，但常常被大家忽略，这时应为我们常会把逻辑放在Façade中，其实这是很错误的。例如：我们可能会提供多种不同Façade以适应不同的访问方式，这样就会出现大量重复的业务逻辑代码。

 

Façade模式

为客户端提供访问业务组件的统一模式。便于实现对不同访问方式的支持（如：远程或本地）。特别在远程调用时通过暴露粗粒度的接口，提高系统的性能。

同时，可以根据客户的不同，通过不同Façade来控制客户的操作。