当前流行的EE框架

1、Struts和WebWork那点事

这两者都是Java开源框架中元老级的产品。Struts分为Struts 1和Struts 2。Struts 1诞生于2001年，是Java EE框架中比较早的基于MVC设计模式的Web开发框架，在Struts 1中视图角色主要由JSP担当，JSP中没有业务逻辑和模型信息，只有用于浏览器窗口显示的Struts、JSP等标签。Struts 1中的控制器由一个核心组件ActionServlet来实现，它负责接收HTTP请求并将其转发给指定的Action对象。Action对象负责调用模型的方法更新模型的状态和控制应用程序的流程。

在Struts 1中组成视图的还有ActionForm Bean，它不像其他的JavaBean被用来处理业务逻辑，而是用来进行视图和控制器之间表单数据的传递。当ActionServlet接收到HTTP请求时，通过ActionMapping寻找需要调用的Action对象，找到后根据客户端浏览器发来的ActionForm Bean创建Action Form对象，再经过一系列的服务器验证，创建一个Action对象并执行其中的execute方法，该方法需要开发者重写，并有可能调用底层的业务逻辑。

Execute方法调用结束后返回一个ActionForward对象，该对象懈怠的是需要反馈给浏览器的具体视图，它将由ActionServlet处理并最终见响应返回到客户端浏览器实现。

Struts 1的工作流程中强制设立了一些必须经过的关卡，在视图和控制器组件需要来回使用ActionForm Bean。另外，Struts 1的可扩展性相对较差，不利于开发人员在其基础上进行修改并增加新的功能。虽然修改其源代码可以解决Struts 1的扩展问题，但是其难度系数可想而知。

Struts诞生后，WebWork框架也诞生了。WebWork框架比较出色，但无奈Struts名头调大，历史悠久，在WebWork要退出WebWork 2的时候，Struts并没有推出一个像样的第二版，在这种背景下，Struts和WebWork的开发社区合并了。合并后的Struts 2完全取代了原有的Struts和WebWork框架。

Struts 2对MVC模式的实现机制如图所示。与Struts 1不同的是，Struts 2支持的视图有很多种，甚至可以用不同的技术去开发，如FreeMarker、Velocity等。Struts 2的控制器由FilterDisPatcher和Action来实现，这点和Struts 1比较类似。Struts 2抛弃了Struts 1中的ActionForm Bean，对MVC模式的诠释也更加干净利落。HTTP请求到达核心控制器后，会经过处理直接找到Action对象执行相关代码，随后便选定一个视图返回浏览器。

Struts 2还只是系统级功能的热插拔。Struts 2自带的而核心系统功能本身就是一堆插件，可以轻松的拔掉之后插上自己的插件，这样也方便对方案进行扩展。需要对框架进行修改时，不需要对源代码进行修改，只需要开发插件，然后通过配置文件对功能进行组装、加新、去旧、替换就可以了。

Struts 2的工作原理：在HTTP请求到来之后，首先经过ActionContextCleanUp等其他过滤器来到FilterDispatcher，之后会来到Action映射器找到需要调用的Action对象，这里类似于Struts 1，之后会通过FilterDispatcher来到Action代理，Action代理通过调用配置管理器查找到所要调用的Action对象搭配的一系列烂机器，然后开始按照顺序调用这些拦截器和Action对象本身。所有这些拦截器都是热插拔的，可以自己开发。例如，原来系统日志都是记录在文本文件中，假设有一天需要将日志改成其他格式进行存放，如果以前把记录日志的功能写在Action里面，那么就必须去修改Action的源代码，这样增加了工作量，可维护性也变差。Action负责用户级功能，而日志、安全性、合法性检查等属于系统级功能，正确的做法是日志让一个拦截器去做就行，这样需要更改的时候只要更换一个新的拦截器就行了，业务开发人员只需要关注用户级的功能即可。

2、Tapestry框架

Tapestry是另外一种开源的Web开发框架，虽然与Struts一样为Web层开发提供解决方案，但是Tapestry的历年却和Struts大不相同。不管Struts 1还是Struts 2，采用的都是请求-响应这一传统的Web工作流程，而Tapestry与后面要介绍的JSJ，都颠覆了这个传统。

Tapestry在英文里是挂毯的意思，在Tapestry开发中的组件就像是挂毯一样通过不断的排列和复用达到Web页面的开发效果。与以往不同，Tapestry应用程序的构成元素就是页面，页面都是由组件构成的，组件还可以包含组件。组件是可以复用的对象，如按钮、文本框、表格等都是组件。

Tapestry中的组件又被称为JWC(Java Web Component)，每个组件都会有一个jwcid以供开发人员调用，海量的组件库简化了Web表示层开发的难度，开发人员可以花更多的经历去做业务逻辑，而负责前端表示的人也可以在不会JSP的基础上使用组件做美工。

Tapestry基于Servlet，其应用产业鞥徐需要运行在Servlet的容器中才行。Tapestry最大的特点是把开发人员从传统框架中需要关注的请求分派、URL转向灯问题中解脱出来，所以不了解Servlet的知识没关系，因为Tapestry会帮助开发人员生成Servlet。

Tapestry的工作原理：所有的HTTP请求都会送达ApplicationServlet，这是Tapestry的核心Servlet。不同Application不做太多的实事，其接收到请求后并调用自己的Service()，以启动Engine对象，并调用Engine对象的Service方法。

Engine对象是Tapestry框架中的枢纽，负责将所有的模块组织到一起。在Engine的service方法中会进行很多工作，其中最主要的是调用Engine Service的service方法。最后逐级返回，吧响应返回给客户端。

Engine Service也是一个Servlet，确切的说是一个做实事的Servlet，在Tapestry中有9种不同的service，如home、page、direct等。

3、Spring-不可多得的好框架

Spring是一个有球的Java EE开源框架，自2004年问世以来就一直受到开发者的好评。Spring框架是一个比较全面的框架，可以为一些企业级应用开发提供一条龙式服务。

1）IoC技术

IoC（Inversion of Control）即控制反转技术，IoC技术注重面向接口的编程，即将对象与对象之间的依赖关系转变为对象与接口之间的关系。IoC又被称为依赖注入（Dependency Injection）和好莱坞原则（Hollywood Rules），这些昵称都会随着对IoC技术介绍的加深而渐渐明朗。

在以往的开发中，一个对象需要有指向另外一个对象的引用，才可以互相调用发生关联，即产生依赖关系。这种对象之间的依赖关系是开发人员手动通过编程实现的。不过手动编程有一个缺陷，就是当对象之间的关系改变时，随之而来的修改工作也大大增加，对象之间关系的改变有如下两种情况：

在开发对象A时需要调用到对象B的功能，假设B为A提供数据库访问功能，由于项目的同时开发，并没有成行的B类对象供调用，此时的解决方案是写一个类来模拟B类的实现，这个模拟类十分简单，只要从API角度提供对象B的功能即可，这样可以保证对象A的测试和项目的继续开发。但是到项目最后，还需要修改代码将模拟类用真正的B类代替。

在项目的开发过程中写出了很多组件，这些组件其实也是对象。而如果希望在部署时能够灵活的组装这些组件，就必须要退回去修改源代码进行对象之间的关联。而且在修改源代码之后，必须要进行重新测试。

以上两种情况的解决方案都需要手动修改代码，实现起来很不方便。既然问题本身是对象的开发和对象的依赖关系更改之间的矛盾，那可不可以将两者彻底剥离开来，开发对象的只管开发对象，而对象之间的依赖关系由外部导入，这就是IoC的开发模式。

IoC的工作原理就是在开发一个对象的时候，在关注起本身的功能之外，只需要留出以后会调用的对象的引用即可。如果在对象的功能开发过程中必须出现所以来对象的引用供调用测试时，就开发实现相同接口的模拟对象来替代，使得对象的功能开发可以继续进行。

当各个组件的功能开发完毕之后，IoC容器就开始发挥作用，IoC容器决定某个对象保留的某个引用指向那个具体对象，并将所有对象之间的依赖关系写入配置文件中。这样如果需要更改对象之间的关系，只需要改动配置文件即可，免去了修改代码的复杂工作。

回到前面所提到的改变对象依赖关系的两种情况，第一种情况下只需要开发一个替代类然后在部署的时候改动IoC配置文件将假的去掉换上真的对象即可；而第二种情况下只需要对IoC配置文件进行合理规划，即可灵活的完成各个组件之间的搭配。

依赖关系的更改实际上是在实现了相同接口的不同对象之中进行替换，这使得对象不必和其他对象绑定而是指向一个拥有很多实现类的接口，这样就大大提高了灵活性。这种开发模式就面向接口编程。

2）Spring AOP的实现原理

AOP即面向方面的编程，AOP就是将散落在软件系统各个角落如日志、安全性等系统级服务提取出来，集中放置在一个地方，谁需要就绑定给谁。这样就大大提高了代码的可重用性，同时当需要对系统级服务进行扩充和修改时，这种封装式的管理也使得系统易于维护。

要进行Spring AOP的开发，需要开发AOP Device，即AOP设备，这是AOP开发中的主要内容，通常有5种装备类型。

Before装备，在执行目标操作之前执行的装备。

Throws装备，如果目标操作在执行的过程中抛出了异常，则该装备执行。

After装备，在执行目标操作之后执行的装备。

Around装备，在执行目标操作前后执行的装备，这种装备功能最强大，能够在目标操作执行前后实现特定的行为，使用最为灵活。

Introduction装备，此种装备能够为类增加方法，在五种装备中最复杂也最难掌握。

Spring AOP的工作原理图。

当客户端需要调用实现业务接口的Spring Bean时，并不会直接获取指定功能Spring Bean的引用，而是将请求告知代理工厂。代理工厂通过查找配置文件，找到目标Spring Bean并根据其有无拦截器，是何种拦截器进行相关装备和业务功能的调用。

这样一来负责开发业务Spring Bean的开发人员就不需要关注这些横切关注点，只要根据实际情况决定业务功能需要什么样的装备即可，而开发装备的人只需要根据系统的要求对不同装备进行开发，最后对业务功能和系统级功能进行组装即可，如合法性检查需要放在Before装备中，而系统日志和出错日志需要放在After装备和Throws装备中。

4、Hibernate-从关系世界到对象世界

谈Hibernate之前需要介绍ORM和POJO。ORM即对象关系映射（Object Relations Mapping），ORM工具将关系数据库中的数据通过某种方式映射成对象。而POJO即Plain Old Java Object，表示简单普通的Java对象。很多初学者最开始经常编写的Car对象、Student对象等都属于POJO。

Hibernate是一个ORM工具，它可以将数据库中的数据库中的数据映射为一个或多个POJO，进而将面对关系数据库的各种业务操作以POJO的属性与方法的形式实现。从而避免开发繁琐的JDBC代码，将精力集中在业务的实现上，这是Hibernate最大的一个优势。

Hibernate的特点就是在与数据库进行关联的时候跳过了JDBC。JDBC是Java语言的数据库接口，其效率高、性能好。通过将数据库编程的代码抽象于不同类型的数据库产品之上并形成统一的API，是的Java的数据库开发能力大大提高。之所以用Hibernate代替JDBC是因为JDBC是直接面向数据库查询语言SQL的，随着应用系统规模的扩大，数据库中表与表之间的关系越来越复杂，JDBC代码也将变得越来越复杂，显然无法胜任关系型数据库和面向对象编程之间的纽带工作。JDBC在应用系统规模很大的情况下很多时候数据库的性能和可靠性主要依赖于程序员的经验和技巧，这对于快速、大规模的开发软件系统是十分不利的。

而Hibernate可以掩盖复杂的JDBC过程，取而代之的是将OR映射后的结果展现在开发者面前，其余需要经验和技巧的设计部分封装在POJO对象和XML映射配置文件中。

在Hibernate框架中，当需要调用数据库的时候，开发人员调用Hibernate的API。由Hibernate负责进行与关系型数据库的交互，随后以POJO对象的方式返回给开发人员。如应用程序从学生数据库中查询成绩优秀者，Hibernate会将每个符合条件的学生信息封装成一个POJO类，并将其返回。这样对开发人员来说就不需要将经历花费在数据库的操作上了。