java EE web开发经常使用框架使用感言

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吧。