目的：
在实际项目中出于稳定性以及团队开发技能我一直没考虑采用Spring框架，最近有时间就计划学习Spring框架，为以后的项目开发做相关的技术储备。
回顾：
开源框架在以前的项目中用过不少， struts,webwork,hibernate,前两者属于web框架，后者属于ORM框架，这些框架基本都是侧重于应用的某个层面，不能称之为J2EE全面的框架，往往是需要和其他框架相结合，我开发的项目采用过如下组合，有的根本就没有框架，只是自己做了设计封装
a、servlet+jdbc,
b、servlet+jsp+javabean+jdbc,
c、struts+BD+DAO ,
d、webwork+ejb+hibernate
使用体会：
a、b就不要说了，那时候的代码结构真是天马行空，我当时初学，维护公司一个项目代码，1个jsp实现一个模块所有功能，我花了好长时间才 读懂代码。
时代总是向前发展的，慢慢的系统结构层次上是越来越清晰，开发效率也越来越高，维护也越来越容易（基于一定的培训成本）。
相对而言出于设计理念来讲，个人更喜欢webwork+hibernate框架组合。
常有人讨论同等开发层面框架的优缺点，我所属产品的另外一个项目团队曾经为项目后续开发 应该采用struts还是webwork争论的不可开交， 其实个人认为struts,webwork都是非常好的web框架，都有自身的优缺点：
struts开创web MVC框架之先河，2003－2004年开发的项目基本都是采用struts框架（当时招聘人的时候常问会不会struts，会基本就招了 ），实际MVC设计理念很早就提出了，在j2SE中有很多使用之处，但当时没有一个web框架开发中很好的贯彻该设计理念，直到struts 出现（可能有，只是没有apache更引人注意）。
struts优点使用用户多，相关技术文档比较全面，开发遇到的问题相关案例也比较多、比较容易解决，框架更加稳定(这一点非常重要）。
webwork相对于struts来讲，的确有不少优异之处，（也是情理之中的事，后发布的框架如果再没有优点别人也不会使用）
个人认为在开发上主要有以下几点：
1、页面数据封装成值对象功能比struts强大，webwork采用ognl类型转化。
struts只能对简单类型的数据对象以及文件对象封装成值对象, 而webwork封装的值对象基本没有限制，值对象属性还可以是List,Map这些对象（这个特性在我们开发一些批量数据、复杂数据处理时非常方便），减少很多代码量，代码非常整洁。
2、拦截器功能
拦截器是webwork的一个亮点，实际上也是业界比较流行的AOP的一个体现，在实际开发中你可以配置默认的拦截器， 也可以为单独的模块指定特定的拦截器，并且可自定义拦截器，action执行前后拦截都可以。
3、单元测试比较方便
最早使用struts框架开发测试时，相关的单元测试基本是不好做的，无法脱离web环境，测试都是只做集成测试、系统测试。
使用webwork可以简单对action相关属性赋值，可以相关的单元测试，当然前提是在对应action中没有引用web环境相关的对象。
其实webwork框架核心还是xwork框架，最早框架使用在C/S结构下，webwork只是xwork的一个在web环境的实现，只是ActionContext 上下文发生了变化，所以说action能够做到脱离web环境也是情理之中的。
4、配置文件
webwork配置文件可以采用引用、继承其他配置文件方式，在团队开发一般都是分模块开发，这样比较方便，配置管理更容易，不会冲突。
5、模板技术集成
我在实际应用项目中是采用velocity模板做视图展现，因为在对应版本的webwork框架中和velociy集成的相当好，比较方便，
比直接写jsp代码更整洁、同时利用velocity模板特性结合每个action的配置文件，可实现比较通用的页面查询、录入等视图的展现。
而struts是没有相关模板集成，不过struts的tag相对而言比webwork的tag好用，webwork如果视图是jsp类型，相关的tag真的比较麻烦
虽然tag 库很丰富，这也是我为什么使用velocity做视图的原因 。
6、 框架的效验功能
老实说，两者框架的效验功能都比较麻烦，相对而言webwork更加麻烦点，配置较多，验证接口实现太麻烦，我实际项目使用中还是
自定义了相关后台验证接口， 要验证的相关action只要实现相关接口即可，相关拦截器负责拦截验证，
大部分的效验根据配置数据以及html对象自定义属性通过javascript通用效验，实际上现在基于XmlHttp的ajax技术应用成熟的话
后台验证接口的用途会逐渐淡化。
说明上述比较版本为 struts 1.0 /webwork 2.1.6，后续struts框架扩展很多功能，不是很了解，可能和上诉描述不一定很吻合。
现在两者已经合并，希望能结合两者的优势，发展出更好web框架。
7、关于Hibernate还是DAO模式，个人建议采用hibernate+DAO相集合的模式，hibernate占主导地位。
虽然DAO模式通过自动生成代码效率不会低，但如果需求变更就比较麻烦，维护修改代码较多，测试工作量也较大， 但Hibernate不是万能的，在一些必要的应用还是采用DAO模式，特别是性能相关的部分。
废话一大堆，也算把我的工作回顾了一遍，呵呵，这两天简单了解Spring框架，个人感觉Spring更像一个全面的J2EE框架解决方案, 希望能够有时间系统的学习一把，大家有兴趣的请多多交流,我会将我的学习心得和大家分享。