多种技术框架的融合转型为一种框架的大一统（spring3.x）

      也许spring3.x all in one的时代来了!

      到目前为止本人java方向的编程经验已经多年了，中间曾经使用过多个技术框架，按照时间顺序（中间有交叉）分别如下：

      1，一套叫做timeless的代码框架。这套框架是2000年左右的一套东西。没有使用任何现代的类型spring之类的框架，自带有权限代码和库设 计。就是jsp+action+dao.分层不清晰，jsp和action比较混淆，dao承担了service和dao的功能。其实其实几乎没有分层概 念，jsp里也有直接调用dao和直接连库操作的。这个是先powerdesigner设计数据库，根据数据库的表直接反向生成全部代码，也是略作改动就 可以部署运行。使用时间大约1年。

      2，以andromda为基础，又经过公司实际需要改良过的一套代码生成工具，由标准的非annotion的方式spring2.x和hibernate3.x组成，自带有权限代码和库设计。我有幸负责了改良的过程。andromda这个项目在08年的时候几乎快要关张大吉，当时版本很久不再更新，页面打开都出异常代码出来，而我们的改良工作就是在08年完成的。当时异常艰难，因为用的人不多，然后文档都不全，他们自己的论坛留言都没人理你。使用时间约两年。

      好了介绍一下这个框架吧，这套框架首先要画uml图，用的工具是MagicDraw UML，然后根据uml图自动生成数据库脚本，web层，service层，和dao层，已经domain和dto，还有页面。直接部署略作改动就可以运行。

     3，自己设计的一套框架，使用了spring2.5.x和hibernate3.3.x，用maven来管理项目,spring security2.5.x来完成权限管理。后台使用extjs3.1单页面来完成。先是用powerdesigner设计整个数据库，然后用hibernate反向生成annotion的domain层。service和dao层做了合并起名为manager层。并且取消了接口原因在于部门人少不用分层开发，这样可以提高效率。manager使用泛型直接继承一个dao模板类，实现curd功能。mvc用了spring的annotion。不能直接部署使用。使用时间半年多。

     4，别人匆忙完成的一套框架，由struts2,spring3,ibatis2组成。无annotion。权限系统使用spring security3完成。为什么说匆忙呢，完成这个框架的人之前本身没有实际使用经验，而且刚完成就离职了，苦了使用者。代码没有任何生成全手工完成。使用时间目前为止3个月了。

     5，期望的框架，也就要改造的把4弄成spring3 all in one.使用sping3的annotion，前端spring mvc，dao使用spring jdbctemlate。maven来做项目管理。全手工代码。

 

 

spring3.x all in one 原因：

       对于我来说，最大原因是之前有spring mvc，jdbc template丰富的使用经验和技术积累，具有技术上的传承性！根据实际实用经验和习惯，spring3.x感觉比struts2和hibernate以及ibatis更顺手。spring3.x all in one升级维护方便，不用考虑多个框架的兼容问题。

      一，spring3.x和struts2对比：

      "spring3与struts2有很大的区别, 最近我们在struts2.1及spring3.0.2上做过压力测试, 发现struts2.1在默认的配制下存在严重的性能问题. 每秒的点击数不会超过200, 而如果用struts2的dispatchServlet去拦截带有参数的jsp如(http://localhost/myapp /my.jsp?para1=1&para2=2) 这样的url时, 在大并发时, 存在很严重的内存泄漏的问题. 用jprofile可以发现java.util.concurrent.concurrenthashmap占用了大量的内存, 同时java.util.concurrent.locks也占用了大量的内存. 原因估计为struts2里面的参数转化拦截器出了问题(没有得到求证)."以上是在坛子里摘抄的。但是性能并不是我决定替换的原因，而且现在没有此问题带来的瓶颈。

      开发之初没有struts2使用经验导致action里的实例变量随着这个类功能不断增加，接着实例变量的混乱使用不可避免，每次对象的生成也将更慢。 我承认这不是struts2本身的问题，也是有办法解决的，但是spring3.x的mvc使用方式天然的避免了这个问题。

     struts2更新缓慢，restful实现困苦，而spring3.x呢，不用说有目共睹。

    二，jdbc template和ibatis2对比：

     不考虑缓存，实际上spring jdbc template也可以缓存。 从效率比spring jdbc template比ibatis2大约快十倍。对与大数量的处理来说是更好的选择。如果有人抬杠说你可以写原生的jdbc呀，那就属于抬杠了，毕竟也要考虑到易用性。

     在使用便捷程度上讲不亚于ibatis，很容易实现对象映射。

 simpleJdbcTemplate.query(sql,
				new BeanPropertyRowMapper(Tbool.class));

 还有把sql写到java中，我个人不认为是件坏事，相对更容易控制。

   三，jdbc template与hibernate对比：

待续。。。。