折腾了一圈的感想

阅读更多

写一个WebGame的开发架构，如何创建持久层呢？需求有：能达到Web应用所要求的效率；能直接使用SQL以方便查询上的优化；有简单的ORM功能，起码要能把查询结果对应到Domain上去。本来打算在JDBC的基础上简单封装一下，但为了省时省力，又试了一下其它的选择方案。

选择一个像Hibernate这样能一揽子解决问题的ORM架构？可想而知的答案，否定，架构复杂，效率不高且跟踪和调优极困难都 是理由。这样庞大的框架还是去做企业应用吧，珍爱生命，远离企业应用！

IBites？效率上倒是比Hibernate应该让人放心一些， 但是把SQL都分离到配置中的做法使用起来怎么都感觉像是脱了裤 子放屁，而且不允许你跳过它的控制直接去操作JDBC对象。还有， Property和Field的关系还要有XML来配置，也太老土了吧，这种东 西，直接用了一个约定来替代不就行了？

找一个简单的封装，在这个基础上进行开发？好像也不容易。从使用的方便性 来说，最寄希望的就是Spring的JdbcTemplate了，虽然对Spring这 个拿着IoC这把锤子到处砸钉子的家伙并没有什么好感，但是就因为 Spring一些封装还真是使用方便而不得不在一个又一个项目中加入 了spring.jar。拿JdbcTemplate爽了一会，总觉得少了点什么，仔 细一看，倒，事务控制呢？看了下Source，JdbcTemplate是 和DateSource挂勾用DataSourceUtils.getConnection()取得Connection的，想控制事务肯定很麻烦，而且越看越觉得……还 不如自己写一个呢。

还是自己来写吧，当然不是从头开始，DbUtils这样的利器还是用得着的。就是JDBC对象的使用，实在啰嗦的很，而且还啰嗦得很有道理……那就层层Try吧。建一个连接池，Connection就用线程池来管理。再说一说事务控制部分，业务逻辑是可以组合的，大的逻辑无非是小的逻辑的合集，写业务逻辑的时候，每个小的模块都声明一下事务的开始和结束，但如果调用时已经声明打开了事务，那这些子模块中的事务就是无效的。也不知道说明白了没有，无非本着一个原规：高层的事务声明优先，打开和提交事务控制在同一层次。从前的项目是配合Hibernate实现的，现在也按着这个思路再实现一次。

转了一圈，又回到了最初的想法。山珍海味吃完了，发现原来还是地瓜最养人呐~