1.2 轻量级Java EE应用相关技术

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

1.2.1 JSP,Servlet和JavaBean及替代技术

JSP

JSP是最早的Java EE规范之一,也是最经典的Java EE技术之一。直到今天,JSP依然广泛地应用于各种Java EE应用中,充当Java EE应用的表现层角色。
JSP具有简单、易用的特点,JSP的学习路线平坦,而且国内有大量JSP学习资料,所以大部分Java学习者学习Java EE开发都会选择从JSP开始。

Servlet

Servlet和JSP其实是完全统一的,二者底层的运行原理是完全一样的。实际上，**JSP必须被Web服务器编译成Servlet,真正在Web服务器内运行的是Servlet** 。从这个意义上来看,JSP相当于一个”草稿”文件,Web服务器根据该”草稿”文件生成Servlet,真正提供HTTP服务的是Servlet,因此广义的Servlet包含了JSP和Servlet。
从目前的Java EE应用来看,纯粹的Servlet已经很少使用了,毕竟Servlet的开发成本太高,而且使用Servlet充当表现层将导致表现层页面难以维护,不利于美工人员参与Servlet开发,所以在实际开发中大都使用JSP充当表现层技术
Servlet3.x规范的出现,再次为Java Web开发带来了巨大的便捷。 Servlet3.x提供了异步请求、注解、**增强的Servlet API、非阻塞I/O**等功能,这些功能都极大地简化了Java Web开发。

JavaBean

由于JSP只负责简单的显示逻辑,因此JSP无法直接访问应用的底层状态,Java EE应用会选择使用JavaBean来传输数据。

数据传输对象 DTO

在严格的Java EE应用中,中间层的组件会将应用底层的状态信息封装成JavaBean集,这些JavaBean也被称为DTO(Data Transfer Object,数据传输对象),并将这些DTO集传到JSP页面,从而让JSP可以显示应用的底层状态。

其他表现层技术

在目前阶段, Java EE应用除了可以使用JSP作为表现层技术之外,还可以使用FreeMarker或Velocity作为表现层技术,这些表现层技术更加纯粹,使用起来更加便捷,完全可作为JSP的替代。

1.2.2 MyBatis3及替代技术

ORM

传统的Java应用都是采用JDBC来访问数据库的,但传统的JDBC采用的是一种基于SQL的操作方式,这种操作方式与Java语言的面向对象特性不太一致,所以Java EE应用需要一种技术,通过这种技术能让Java以面向对象的方式操作关系数据库。
这种特殊的技术就是ORM(Object Relation Mapping),最早的ORM是Entity EJB( Enterprise JavaBean),EJB就是经典Java EE应用的核心,从EJB1.0到EJB2.x,许多人会觉得EJB非常烦琐,所以导致EJB备受诟病。

Hibernate

在这种背景下, Hibernate框架应运而生。 Hibernate框架是一种开源的、轻量级的ORM框架,它允许将普通的、传统的Java对象(POJO)映射成持久化类,允许应用程序以面向对象的方式来操作POJO,而Hibernate框架则负责将这种操作转换成底层的SQL操作。

Hibernate缺点

大多数情况下(特别是对新项目、新系统的开发而言), Hibernate这样的机制无往不利,大有一统天下的势头。但是,在一些特定的环境下, Hibernate这种一站式的解决方案却未必适合。如:

• 系统的部分或全部数据来自现有数据库,出于安全考虑,只对开发团队提供几条Select SQL(或存储过程)以获取所需数据,具体的表结构不予公开。
• 开发规范中要求,所有牵涉到业务逻辑部分的数据库操作,必须在数据库层由存储过程实现(就金融行业而言,工商银行、中国银行、交通银行等商业银行都曾在开发规范中严格指定)
• 系统数据处理量巨大,性能要求极为苛刻,这往往意味着我们必须通过经过高度优化的SQL语句(或存储过程)才能达到系统性能设计指标。

MyBatis

面对这样的需求, Hibernate不再适合,甚至无法使用。此时,直接使用JDBC进行数据库操作实际上也是不错的选择,只是拖沓的数据库访问代码、乏味的字段读取操作令人厌烦,而“半自动化”的MyBatis,却正好解决了这个问题。

半自动化ORM

这里的“半自动化”,是相对Hibernate等提供了全面的数据库封装机制的“全自动化”ORM实现而言的,“全自动”ORM实现了POJO和数据库表之间的映射,以及SQL的自动生成和执行。
而MyBatis的着力点,则在于POJO与SQL之间的映射关系。也就是说,使用MyBatis提供的ORM机制,对业务逻辑实现人员而言,面对的是纯粹的Java对象,这与通过Hibernate实现ORM基本一致,而对于具体的数据操作,Hibernate会自动生成SQL语句,但MyBatis则并不会自动生成SQL语句。具体的SQL需要程序员编写,然后通过映射配置文件,将SQL所需的参数以及返回的结果字段映射到指定的POJO。
相对Hibernate等“全自动”ORM机制而言, MyBatis以SQL开发的工作量和数据库移植性上的让步,为系统设计提供了更大的自由空间。作为对“全自动”ORM实现的种有益补充, MyBatis的存在具有特别的意义。
MyBatis是Apache组织提供的一个轻量级持久层框架,是一个支持普通SQL查询、存储过程和高级映射的优秀持久层框架。 MyBatis消除了几乎所有的JDBC代码和参数的手工设置过程以及对结果集的检索封装。 MyBatis可以使用简单的XML或注解来进行配置和原始映射,将接口和Java的POJO映射成数据库中的记录。

剥离SQL

MyBatis作为持久层框架,其主要思想是将程序中的大量SQL语句剥离出来,配置在配置文件中,实现SQL的灵活配置。这样做的好处是将SQL与程序代码分离,可以在不修改程序代码的情况下,直接在配置文件中修改SQL。
除此之外, Oracle的TopLink、 Apache的OJB都可作为替代方案。但由于种种原因,它们并未得到广泛的市场支持,所以这两个框架的资料、文档相对比较少,选择它们需要一定的勇气和技术功底。

1.2.3 Spring5及替代技术

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

Spring使用的设计模式

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

Spring优点

完美整合SpringMVC

Spring框架号称Java EE应用的一站式解决方案, Spring本身提供了一个设计优良的MVC框架:Spring MVC。使用Spring框架可以直接使用该MVC框架。由于Spring框架拥有极高的市场占有率,因此越来越多的Spring框架的使用者使用Spring MVC替代曾经的MVC框架的王者Struts2。

可以整合其他MVC框架

当然, Spring也可以无缝地整合Struts2、JSF等优秀的MVC框架。
Spring框架并未提供完整的持久层框架,Spring能与大部分持久层框架无缝整合MyBatis、 Hibernate、JPA、 TopLink,更甚至直接使用JDBC,随便你喜欢,无论选择哪种持久层框架, Sping都会为你提供无缝的整合和极好的简化。

中间容器 承上启下

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

1.2.4 使用开源框架的好处

以上提到的Struts2、 MyBatis3、 Hibernate5、 Spring5等都是Java领域最常见的框架,这些框架得到开发者广泛的支持,它们能极大地提高Java EE应用的开发效率,并能保证应用具有稳定的性能。
今天, Spring MVC+MyBatis已成为电商项目架构的最佳搭配。本书将重点讲解含越来越多的企业开始选择Spring MVC+MyBatis来构建系统架构,本书将重点讲解Spring MVC+ MyBatis如何无缝整合开发Java EE项目。

为什么需要使用框架

真实的企业应用开发有两个重要的关注点:可维护性和复用

可维护性

先从软件的可维护性来考虑这种说法。全部采用JSP和Servlet的应用,因为分层不够清晰,业务逻辑的实现没有单独分离出来,从而造成系统后期维护困难。

软件复用

从软件复用角度来考虑。这是一个企业开发的生命,企业以追求利润为最大目标企业希望以最快的速度,开发出最稳定、最实用的软件。因为系统没有使用任何框架每次开发系统都需要重新开发,重新开发的代码具有更多的漏洞,这就增加了系统出错的风险;另外,每次开发新代码都需要投入更多的人力和物力。
以笔者多年的实际开发经验来看,每个公司都会有自己的基础类库,这就是软件的复用,这些基础类库将在后续开发中多次被重复使用。例如,信息化系统,其中总有一些开发过程是重复的,为什么不将这些重复开发工作抽象成基础类库呢?这种抽象既提高了开发效率,而且因为重复使用,也降低了引入错误的风险。

使用框架无法避免

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

第三方框架更好

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