考虑了一段时间后,我初步的做法是这样:
在J2EE架构中,数据是通过使用ValueObject模式在各层中传递,而数据访问则是使用DAO模式,这两个模式共同构建了数据访问层,数据访问层与业务层之间通过ValueObject联系起来.
我觉得这个ValueObject如何设计与DAO的设计是联系在一起的,我现在试图建立的数据访问层是基于独立的主键生成策略,采用定制集合的方式,返回的仅仅是主键的一个collection,只有当客户调用了read方法后才真正的读取相应的数据.
我之所以这样做是因为我找不到比较好的O/R Map方法,只好自己手工做,因此我的DAO使用了template模式,自己写SQL,完成O/R Map. 因为我不打算用EJB和JDO,而是只用JDBC.
我大概地分析了一下,这种做法的性能瓶颈在于连接池的大小和性能,因为所有的操作都是迅速释放连接的,相对于数据处理过程,取得连接代价更为昂贵.
缺点也很明显,就是要频繁的连接数据库,虽然时间短但并发问题没有彻底解决,只是减小了发生的几率.
我现在正为事务和并发这两个老问题伤脑筋,按理事务是不应在数据访问层解决,数据访问层应该是连接数据库的底层事务处理与业务层的商业事务处理.另外还得自己写SQL,不够OO,不够自动化.
大家能给点意见吗?