java EE web项目开发，从前到后...
从访问地址到处理完成转到JSP页面的转向方式：Struts:采用XML配置文件方式，路径配置集中。
Spring MVC:采用标记注入和return页面方式，路径配置分散在每个java文件中。
从对比中，我觉得Spring的这种方式存在难于集中维护项目路径的缺憾。而Struts这种方式，我们就可以很方便集中的管理项目的路径。如果项目已经很庞大，路径很多，我们现在还要在这个项目上做新东西，继续加新路径来完成新业务的访问。在Struts中，我们就可以很方便的通过查看仅有的那几个XML配置文件来确定我们要新加的路径是否和已有的存在冲突、重复等。而spring在这时就显得很悲剧了，路径分散在各个controller java文件中，你要怎么去确定呢，难道一个一个打开去看它们占有的路径？
这时你可以说，可以用eclipse来查所有的controller吖，也很简单就能确定是否和已有路径冲突。当然这样的思路可以解决大部分问题，但不是全部。首先，spring的@RequestMapping 路径定义标签是可以作用于类，也可以作用于方法的，且都允许“/”路径符号。问题随之而来，“/a/b/c/d”这样的路径，就可以分成数种写法而分开写在controller类上或类中的具体方法上，当有人把它们分段写开的时候，你还怎么来查你想定义的路径是否已经存在呢？而对于Struts，上面的那种路径，你只能写成namespace="/a/b/c"，然后在其中定义action的name="d"，因为Struts的name默认是不允许“/”路径符号的，这时你的查找就变的很简单。
上面说明的特点，就Struts来说，也更便于后来者来根据访问路径快速找到具体的处理方法，这样后来者要维护或改动action时就在找到目标这个事情上节省很多功夫。
同时spring的这种return到jsp页面的方式，让人真怀疑是不是又要返回servlet时代。同时大量的路径类字符串被写在java类中（@RequestMapping中的、最后的return中的）总让我觉得不是一个很好的方式，绑的太死的感觉。
就spring的路径维护来说，如果项目组有一个很好的controller类的管理方式，当然也能很大程度上减少路径方面带来的困扰。比如com.xx.aProject.controller总包下，所有的controller java类文件都有一个和它访问路径对应的包结构，并在controller类上就使用@RequestMapping来标识此类的总访问路径，同时要求方法的@RequestMapping定义上不许使用“/”路径符号。如上面提到的路径，对应的类文件就应该是com.xx.aProject.controller.a.b包下的c.java文件，d方法。在类上使用@RequestMapping(value = "/a/b/c"),具体处理方法上使用@RequestMapping(value = "/d")。
综上，struts适合作为路径超多的大型超大型项目的路径管理策略，而srping就显得单薄了；同时spring却提供了一种快速配置方案，而这种策略则较适合访问路径不多且相对开发完成很少改动的中小型项目。当然，我个人认为，“Spring MVC的出现象征着Struts的末日”这种说法，有点太夸大了点Spring。
中间业务逻辑处理类的管理：
很汗颜，我没有接触过这一层的除Spring外的其它框架，所以还是Spring吧，不说其它了。
最后的数据库访问：
hibernate：封装的非常完全，而且现在支持model类内的标签注入类与表的关系、属性与表字段的关系。
ibatis/mybatis:全手写SQL，并将其放入XML文件中，在java中通过ID标记调用XML中的SQL语句执行的方式。
JDBC：不说了，大家刚开始学习时都从它开始的。
上面已经说明的方式，注定了hibernate的优点，开发DAO层代码快速简单，同时也注定了它的缺点，查询速率不佳，因为框架本身要兼顾多款数据库，所以我们调用一个简单查询时，它会运行许多兼顾左右的"废话"；同时需要与JDBC配合起来使用才能达到项目要求，一般都这样，因为hibernate不可能想到你的全部查询需求，有时你必须在java中拼接SQL或者HQL，然后调用JDBC来完成查询。那么，使用hibernate，你就注定了要看在java文件中写的到处是的乱七八糟的SQL语句，然后把你恶心个半死。在java文件中拼接字符串，而且是很容易拼接错误的SQL语句（单引号，双引号之类），而且一般hibernate没提供的查询都是复杂查询，SQL语句串又臭又长，这对很多程序员来说是个看到就头疼的挑战。
ibatis/mybatis相对于SQL语句方面的处理策略就使得开发人员舒心了很多，并且不用再用JDBC。你也不用再在java文件中拼接SQL语句了（最少不用恶心了），同时因为所有SQL是你自己针对自己当前使用的数据库编写的，查询效率完全由你而定，如果你是个SQL高手，那么恭喜你。但这样的方式也有它的缺点，所有的SQL都要你自己一个一个写，这样相对于hibernate，开发效率上就有所不及，但如果已经有了一个固定的开发模式，这个问题基本还很容易解决，复制已有XML，改改里面的表名类名字段名而已。
综上，你给自己做项目，并且希望它查询响应快速，代码优雅，便于以后DAO层维护，那就ibatis/mybatis吧；如果你只是接单来做项目，工期紧张，想省成本，也不用以后回头来看那些恶心的java中SQL，那就hibernate吧。
来源：oschina
链接：https://my.oschina.net/u/176115/blog/51301