1.2 轻量级JavaEE应用相关技术

轻量级应用以传统的JSP作为表现层技术，以一系列开源框架作为MVC层、中间层、持久层解决方案，并将这些开源框架有机地组合在一起，使得Java EE应用具有高度的可扩展性、可维护性。

1.2.1 JSP、Servlet3.x和JavaBean及替代技术

JSP是最早的Java EE规范之一，也是最经典的Java EE技术之一，直到今天，JSP依然广泛地应用于各种Java EE应用中，充当Java EE应用的表现层角色。

JSP具有简单、易用的特点，JSP的学习路线平坦，而且国内有大量JSP学习资料，所以大部分Java学习者学习Java EE开发都会选择从JSP开始。

Servlet和JSP其实是完全统一的，二者在底层的运行原理是完全一样的，实际上，JSP必须被web服务器编译成Servlet，真正在web服务器内运行的是Servlet。从这个意义上来看，JSP相当于一个“草稿”文件，Web服务器根据该“草稿”文件来生成Servlet，真正提供HTTP服务的是Servlet，因此广义的Servlet包含了JSP和Servlet。就目前的Java EE应用来看，纯粹的Servlet己经很少使用了，毕竟Servlet的开发成本太高，而且

使用Servlet充当表现层将导致表现层页面难以维护，不利于美工人员参与servlet开发，所以在实际开发中大都使用JSP充当表现层技术。

Servlet规范的出现，再次为Java web开发带来了巨大的便捷，提供了异步请求、注解、增强的Servlet API、非阻塞IO，这些功能都很好地简化了Java web开发。

由于JSP只负责简单的显示逻辑，所以JSP无法直接访问应用的底层状态，Java EE应用会选择使用Java Bean来传输数据，在严格的Java EE应用中，中间层的组件会将应用底层的状态信息封装成Java Bean集，这些Java Bean也被称为DTO（Data Transfer Object,数据传输对象），并将这些DTO集传到JSP页面，从而让JSP可以显示应用的底层状态。

在目前阶段，JavaEE应用除了可以使用JSP作为表现层技术之外，还可以使用FreeMarker或Velocity充当表现层技术，这些表现层技术更加纯粹，使用更加简捷，完全可作为JSP的替代。

1.2.2 Struts2.3及替代技术

Struts是全世界最早的MVC框架，其作者是JSP规范的制定者，并参与了Tomcat开发，所以Struts从诞生的第一天起，就备受Java EE应用开发者的青睐。多年来，struts确实是Java EE应用中使用最广泛的MVC框架，拥有广泛的市场支持。

Struts框架学习简单，而且是全世界应用最方便的MVC框架，所以互联网上充斥着大量Struts的学习资料，这使得普通学习者可以非常容易地掌握Struts的用法。

从另一方面来看，Struts框架毕竟太老了，无数设计上的硬伤使得该框架难以胜任更复杂的需求，于是古老的Struts结合了另一个优秀的MVC框架：WebWork，分娩出了全新的Struts2，Struts2拥有众多优秀的设计，而且吸收了传统struts和WebWork两者的精华，迅速成为框架中新的王者。

Struts2框架目前的最新版本是struts2.3，虽然struts2.3如此优秀，但在MVC框架领域还有另外两个替代者：springMVC和JSF。

l springMVC是spring框架所提供的开源MVC框架，由于spring框架拥有极高的市场占有率，因此导致springMVC也拥有不错的市场表现。

l JSF是Oracle所推荐的Java EE规范，拥有最纯正的血统，而且Apache也为JSF提供了MyFaces实现，这使得JSF具有很大的吸引力。

提示：

从设计上来看，JSF比Struts2理念更加优秀，它采用的是传统RAD（快速应用开发）理念。只是struts早就深入人心，所以导致JSF在市场占有率上略逊一筹。

1.2.3 Hibernate4.3及替代技术

传统的Java应用都是采用JDBC来访问数据库的，但传统的JDBC采用的是一种基于SQL的操作方式，这种操作方式与Java语言的面向对象特征不太一致，所以Java
EE应用需要一种技术，通过这种技术能让Java以面向对象的方式操作关系数据库。

这种特殊的技术就是0RM（Object Relation Mapping)，最早的0RM是Entity EJB（Enterprise

Java Bean），EJB就是经典Java EE应用的核心，从EJB1.0到EJB2.x，许多人觉得EJB非常烦琐，所以导致EJB备受诟病。

在这种背景下，Hibernate框架应运而生，Hibernate框架是一种开源的、轻量级的ORM框架，它允许将普通的、传统的Java对象（POJO)映射成持久化类，允许应用程序以面向对象的方式来操作POJO，而Hibernate框架则负责将这种操作转换成底层的SQL操作。经过长时间的发展，现在的Hibernate已经逐渐稳定下来，Hibernate的最新版本是4.3。

再后来，sun公司果断地抛弃了EJB2.x规范，引入了JPA规范。JPA规范其实是一种ORM规范，因此它的底层可以使用Hibernate、TopLink等任意一种ORM框架作为实现。很明显，如果应用程序面向JPA编程，将可以让应用程序既可利用Hibernate的持久层技术一一因为可以用Hibernate作为实现；也可以让应用程序保持较好的可扩展性一一因为可以在各种ORM技术之间自由切换。除了可以使用Hibernate这种ORM框架之外，轻量级Java EE应用通常还可选择MyBatis框架作为持久层框架，MyBatis是Apache组织提供的另一个轻量级持久层框架，MyBatis允许将SQL语句查询结果映射成对象，因此常常也将MyBatis称为SQL Mapping工具。除此之外，Oracle的TopLink、Apache的OJB都可作为Hibernate的替代方案，但由于种种原因，它们并未得到广泛的市场支持，所以这两个框架的资料、文档相对较少，选择它们需要一定的勇气和技术功底。

1.2.4 Spring4.0及替代技术

如果你有5年以上的Java EE开发经验，并主持过一些大型项目的设计，你会发现spring框架似曾相识，Spring甚至没有太多的新东西，它只是抽象了大量Java EE应用中的常用代码，将它们抽象成一个框架，通过使用spring可以大幅度地提高开发效率，并可以保证整个应用具有良好的设计。

spring框架里充满了各种设计模式的应用，如单例模式、工厂模式、抽象工厂模式、命令模式、职责链模式、代理模式等，spring框架的用法、源码则更是一道丰盛的Java大餐。

spring框架号称Java EE应用的一站式解决方案，spring本身提供了一个设计优良的MVC框架：springMVC，使用spring框架则可直接使用该MVC框架。但实际上，spring并未提供完整的持久层框架一一一这可以理解成一种“空”，但这种“空”正是spring框架的魅力所在——Spring能与大部分持久层框架无缝整合：Hibernate？JPA？MyBatis？TopLink？更甚至直接使用JDBC？随便你喜欢，无论选择哪种持久层框架，spring都会为你提供无缝的整合以及极好的简化。

从这个意义上来看，spring更像一种中间层容器，spring向上可以与MVC框架无缝整合，向下可以与各种持久层框架无缝整合，的确具有强大的生命力。由于spring框架的特殊地位，所以轻量级Java EE应用通常都不会拒绝使用Spring。实际上，轻量级Java EE这个概念也是由spring框架衍生出来的，spring框架暂时没有较好的替代框架。

spring的最新版本是4.0.4，上面介绍的struts2.3、Hibernate4.3和spring4.0都是Java领域最常见的框架，这些框架具有广泛的开发者支持，能极好地提高Java EE应用的开发效率，并能保证应用具有稳定的性能。但常常有些初学者，甚至包括一些所谓的企业开发人士提出：为什么需要使用框架？用JSP和Serviet己经足够了。

提出这些疑问的人通常还未真正进入企业开发，或者从未开发一个真正的项目。因为真实的企业应用开发有两个重要的关注点：可维护性和复用。

先从软件的可维护性号虑这种说法，对采用JSP和Servlet的应用，因为分层的不清晰，

业务逻辑的实现没有单独分离出来，造成系统后期维护困难，甚至在开发初期，如果多个程序员习惯迥异，也可能造成业务逻辑实现位置小同而冲突。

从软件复用角度来考虑，这是一个企业开发的生命，企业以追求利润为最大追求目标，企业希望以最快的速度，开发出最稳定、最实用的软件。因为系统没有任务框架，每次开发都需要重新开发，重新开发的代码具有更多的漏洞，这增加了出错的风险：另外，每次开发新代码都需要投入更多的人力和物力。

以多年的实际开发经验来看，即使在早期使用PowerbuiIder和Delphi开发的时代，每个公司都会有自己的基础类库一一一这些就是软件的复用，这些基础类库将在后续开发中多次重复使川“对信息化系统而言，总有一些开发过程是重复的，为什么不将这些重开发抽象成基础类库，这样提高了开发效率，而且因为重复使川，也降低了引入错误的风险。

因此只要是一个有实际开发经验的软件公司，就一定会有自己的基础类库，这就需要使用架构的原因。从某个角度来看，框架也是一基础类库，它抽象了软件开发的步骤，让实际开发人员可以直接利用这部分实现。当然，即使使用JSP和Servlet开发的公司，也可以抽象出白己的基础类库，那么这也是框架！一个从事实际开发的软件公司，不管他是否意识到，他自己在使用框架，区别只有：使用的框架到底是别人提供的，还是白己抽象出来的。

到底是使用第三方提供的框架更好，还是使用自己抽象的框架更好？这个问题就见仁见智了，通常而言，使用第三方提供的框架更加稳定，更有保征，因为第三方提供的框架往往经过了更多人的测试，使用自己抽象的框架则更加熟悉底层运行原理，出了问题更好把握。如果不是有非常特殊的理由，还是推荐使用第三方框架，特别是那些流行的、广泛使川的、开源的框架。

转载请注明出处http://blog.csdn.net/wolaiye320/article/details/51367567