我也正在做这方面的尝试,希望能多交流.
在J2EE架构中,数据是通过使用ValueObject模式在各层中传递,而数据访问则是使用DAO模式,
这两个模式共同构建了数据访问层,数据访问层与业务层之间通过ValueObject联系起来.
我觉得这个ValueObject如何设计与DAO的设计是联系在一起的,我现在试图建立的数据访问层
是基于独立的主键生成策略,采用定制集合的方式,返回的仅仅是主键的一个collection,只有当
客户调用了read方法后才真正的读取相应的数据.
我之所以这样做是因为我找不到比较好的O/R Map方法,只好自己手工做,因此我的DAO使用了template
模式,自己写SQL,完成O/R Map.
我大概地分析了一下,这种做法的性能瓶颈在于连接池的大小和性能,因为所有的操作都是迅速释放连接
的,相对于数据处理过程,取得连接代价更为昂贵.
这种方式的优点是可以方便的控制数据的获得,减少无用数据的提取和传输,而商业逻辑和数据访问层可以
清晰的分开.
缺点也很明显,就是要多次的连接数据库,虽然时间短但并发问题没有彻底解决,只是减小了发生的几率.
我现在正为事务和并发这两个老问题伤脑筋,按理事务是不应在数据访问层解决,数据访问层应该是连接数据
库的底层事务处理与业务层的商业事务处理.另外还得自己写SQL,不够OO,不够自动化.
我现在的感觉是这些东西是牵一发而动全身,得从整个系统框架上来考虑.用不用EJB,这些问题的合适解完全
不一样,考不考虑移植又不一样,甚至选用什么数据库又不一样.
我碰到的问题和only you兄一样,但我想咱们选择的解法可能会完全不同,但也可以说是完全一样:都会使用DAO
和ValueObject,差别的产生在于实现DAO的方式,我选择JDBC和标准类,但也可以用EJB和JDO,最低层的实现不同
数据的返回方式也就不同,但所有的这些对业务层来说都应该是透明的
归根结底还是O/R Map的问题,这个问题的根源又在于Java在参数化数据类型上做得不够好--或者是我不会,还请
大家多指教.(我专门为此开了一帖 http://www.delphibbs.com/delphibbs/dispq.asp?lid=1511083)
咳,越抽象的解法越不能解决具体的问题,但却能越多的概括问题的实质.或许我们的价值就在于在将抽象的东西
具体化吧
only you兄,说错了还请多指正啊 ^0^
也说说你的想法吧,我也头疼着呢~~~~