J2EE 核心模式（Core J2EE Patterns）学习随心理解、随手记录（六）

集成层模式：

 

数据访问对象：Data Access Object。提炼和封装对持久化存储介质的访问。DAO封装了数据源的实现细节，总是面向API调用者提供统一的接口。DAO应当被实现为无状态的对象，这样就可以成为轻量的对象，不需要考虑线程、同步、缓存等问题，而把这些问题下沉到数据层去完成。

以我参与的项目的缓存的使用举例，模型DAO并不做任何的缓存行为，数据库使用自身的缓存能力，并且在必要时冗余字段，这是基于数据粒度的基础缓存；到了调用DAO的业务层面，比如Service层，才进行业务模型粒度的缓存，比如缓存某些用户对象等；而DAO层实现了基础DAO的约束，继承了Spring给DAO封装的基础能力，比如事务控制的能力等，所有方法都不使用类状态变量，找不到任何对用户会话对象访问的逻辑，也看不到任何java.sql包内的类和对象（尤其是异常）。

 

服务激活器：Service Activator。用于接收异步请求，由异步请求来触发业务。JMS监听器是一个常用的实现者，JMS目标通常有两种，一种是主题，即Topic，用于点对面的通知；一种是队列，即Queue，用于点对点的通知。

解决方案中的请求通常都由界面侧触发，因此服务激活器通常被放置在内部部件（例如计费部件）上，计费业务的请求由展现部件经过总线转发给计费部件触发计费服务流程。

 

业务领域存储：将持久化逻辑从对象模型中分离出去。比如最常用的BMP和CMP，无需根据不同的业务对象类型建立不同的数据库脚本，只需要维护好业务领域侧的模型配置，存储事件是透明的。

业务领域存储的实现有很多种方式，比如Grails内部使用规约配置和Hibernate的持久化管理能力，让存储的逻辑完全透明，映射关系的配置和映射表建表和CRUD的sql语句都可以由规约代替，于是可以不进行任何的映射配置来实现存储，真正做到透明存储。

再比如：上述的关系型数据库下，数据库表和业务模型是有映射关系的，也就是常说的横表；但是也可以使用纵表，实现数据模型的任意扩展，这就是一个通过改变存储方式来实现持久化逻辑完全不依赖于对象模型的例子。

此外提一下nosql，海量数据的存储可以是稀疏的，水平扩展性、查询性能优异，尤其适合海量存储，它减弱了数据之间在存储层面上相互之间的约束，介绍见此。

 

文章系本人原创，转载请注明作者和出处