常用的Java Web框架简介

Web框架是人们在使用某种语言编写Web应用服务端时关于架构的最佳实践。 
有些Web框架是从实际的Web项目抽取出来的，也就是说，做一个具体的应用项目时，采取的架构比较理想，就把这部分和领域无关，而仅和Web的请求和响 应处理有关的设计拿出来，形成一个基础，在开发别的应用项目的时候则可以从这基础做起，让开发者更关注领域问题，而不是Web的请求和响应的控制。
也有些Web框架是直接设计出来的，很多Web框架在设计的时候也都借鉴了别的框架，吸取优点，修改不足，并根据自己的框架的定位，在特定方面有自己的发 挥，形成了自己的特点，比如有的web框架追求的是松耦合性，层次，结构之间都不密切绑定，有的Web框架则追求敏捷性，强调约定而不是配置。
Java 的 Web框架虽然各不相同，但基本也都是遵循特定的路数的：使用Servlet或者Filter拦截请求，使用MVC的思想设计架构，使用约定，XML或 Annotation实现配置，运用Java面向对象的特点，面向抽象实现请求和响应的流程，支持Jsp，Freemarker，Velocity等视 图。

JSF 
优点： 
Java EE标准，这意味着有很大的市场需求和更多的工作机会 
上手快速并且相对容易 
有大量可用的组件库 
缺点： 
大量的JSP标签 
对REST和安全支持不好 
没有一个统一的实现。既有SUN的实现，又有Apache的实现——MyFaces。 
国内的OperaMasks还支持AJAX，以及有开发工具 支持

Spring MVC 
优点： 
对覆盖绑定（overriding binding）、验证（validation）等提供生命周期管理 
与许多表示层技术/框架无缝集成：JSP/JSTL、Tiles、Velocity、FreeMarker、Excel、XSL、PDF 等 
便于测试——归功于IoC 
缺点： 
大量的XML配置文件 
太过灵活——没有公共的父控制器 
没有内置的Ajax支持

Stripes 
优点： 
不需要书写XML配置文件 
良好的学习文档 
社区成员很热心 
缺点： 
社区比较小 
不如其他的项目活跃 
ActionBean里面的URL是硬编码的 

Struts 2 
优点： 
架构简单——易于扩展 
标记库很容易利用FreeMarker或者Velocity来定制 
基于控制器或者基于页面的导航 
缺点： 
文档组织得很差 
对新特征过分关注 
通过Google搜索到的大多是Struts 1.x的文档

Tapestry 
优点： 
一旦学会它，将极大地提高生产率 
HTML模板——对页面设计师非常有利 
每出一个新版本，都会有大量的创新 
缺点： 
文档过于概念性，不够实用 
学习曲线陡峭 
发行周期长——每年都有较大的升级

Wicket 
优点： 
对Java开发者有利（不是Web开发者） 
页面和显示绑定紧密 
社区活跃——有来自创建者的支持 
缺点： 
HTML模板和Java代码紧挨着 
需要对OO有较好的理解 
Wicket逻辑——什么都用Java搞定
在Java的Web框架中，我使用过Struts1，Struts2，试用过Stripes，Wicket，了解过JSF，SpringMVC。以我使用的经验，我觉得看一个Java Web框架应看看下面几个方面：
1.设计理念
一个框架设计出来应该有一个基本的思路，它为什么要要被设计出来？有的框架的目标 就是提高效率，有的框架的目标的给用户充分的选择，有的框架的目标是充分了解实际需求，给用户一个尽量合理的默认选择，有的框架是要给使用者开发桌面程序的感觉。应该说，一个好的框架应该是实现了预期目标，体现出了自己的设计理念的。
2.设计的合理性
设计的合理性表现在框架在一些关键问题上的处理，比如灵活性和敏捷性之间的权衡，硬编码和文本配置之间的权衡。灵活性指的是可以适应用户多样的需求，很特 殊的要求也能得到支持，有的框架的实现基于太多的约定，使得用户只能遵循。而敏捷性指的是用户在解决绝大多数常规问题的时候，能尽量少做工作，提高效率。 框架设计者只能在这两者见达到一个平衡点，权衡的怎么样，就很见水平了。硬编码和文本配置之间的权衡也很有意思，文本配置的意义在于Java是一个编译语 言，强调代码的封闭，讲究扩展而不是修改，这种情况下文本配置信息可以很方便的在不修改程序的情况下改变程序行为，但是随着一些灵活的脚本语言实现的 Web框架的出现，人们发现在这样的框架中，脚本语言即做程序编码语言，也做配置语言，还做视图上的标记语言，这使我们对Java实现的框架有了一番新的 审视，既然配置文件并没有消除对程序的修改，为什么不能在应编码上下下功夫呢？
3.设计的平衡性
设计的平衡性指的是，框架在设计流程中各阶段，各层次的实现方式时，所达到的上述权衡（灵活性和敏捷性之间的权衡等）应该是具有一致的水平。一个在控制上过分灵活，而视图上具有非常大限制的框架是不能算做一个好的框架的。
4.框架真的解放了开发者吗
框架的目的是让开发者把更多的精力放在领域问题，而非Web的请求和响应的处理问题上。而事实上框架都做到这一点了吗？不可否认，框架的使用提高代码的可 维护性，但是框架在解放开发者这点上就未必了，有时还给开发者带来了额外的负担。事实上，直接使用Servlet，只要维持好代码风格，一样可以很有效 率，当然，直接使用Servlet的灵活性就不用说了。
在我接触的Web框架中，我最推崇的是Struts2，设计优雅，偏重灵活，也基本不造成额外的负担，当然这些评价是和我参与的项目的规模有关的，其他规模的项目Struts2就未必合适了。我希望Struts2能在下面几个方面有些改善：
1.在提供文本配置方式的基础上给一个约定配置的方式，让开发者在大多数情况下可以不配置。
2.配置也支持硬编码，因为有时候维护可修改的硬编码是很有效率的。

3.在拦截请求上，能借鉴下ROR，Django的思路，适应新的Url的需求，考虑大家对“?”后添加属性的回避，支持带占位符的Url。

有些Web框架是从实际的Web项目抽取出来的，也就是说，做一个具体的应用项目时，采取的架构比较理想，就把这部分和领域无关，而仅和Web的请求和响应处理有关的设计拿出来，形成一个基础，在开发别的应用项目的时候则可以从这基础做起，让开发者更关注领域问题，而不是Web的请求和响应的控制。

也有些Web框架是直接设计出来的，很多Web框架在设计的时候也都借鉴了别的框架，吸取优点，修改不足，并根据自己的框架的定位，在特定方面有自己的发挥，形成了自己的特点，比如有的web框架追求的是松耦合性，层次，结构之间都不密切绑定，有的Web框架则追求敏捷性，强调约定而不是配置。

Java 的 Web框架虽然各不相同，但基本也都是遵循特定的路数的：使用Servlet或者Filter拦截请求，使用MVC的思想设计架构，使用约定，XML或 Annotation实现配置，运用Java面向对象的特点，面向抽象实现请求和响应的流程，支持Jsp，Freemarker，Velocity等视图。

JSF

优点：

Java EE标准，这意味着有很大的市场需求和更多的工作机会

上手快速并且相对容易

有大量可用的组件库

缺点：

大量的JSP标签

对REST和安全支持不好

没有一个统一的实现。既有SUN的实现，又有Apache的实现——MyFaces。

国内的OperaMasks还支持AJAX，以及有开发工具 支持

Java EE开发四大常用框架

我们对Java EE的框架有过很多介绍， 本文将对Java EE中常用的四个框架做一下系统的归纳，希望大家喜欢。

 

Struts

Struts是一个基于Sun Java EE平台的MVC框架，主要是采用Servlet和JSP技术来实现的。

 

Struts框架可分为以下四个主要部分，其中三个就和MVC模式紧密相关：

 

1、模型 (Model)，本质上来说在Struts中Model是一个Action类(这个会在后面详细讨论)，开发者通过其实现商业逻辑，同时用户请求通过控制器(Controller)向Action的转发过程是基于由struts-config.xml文件描述的配置信息的。

 

2、视图(View)，View是由与控制器Servlet配合工作的一整套JSP定制标签库构成，利用她们我们可以快速建立应用系统的界面。

 

3、控制器(Controller)，本质上是一个Servlet，将客户端请求转发到相应的Action类。

 

4、一堆用来做XML文件解析的工具包，Struts是用XML来描述如何自动产生一些JavaBean的属性的，此外Struts还利用XML来描述在国际化应用中的用户提示信息的(这样一来就实现了应用系统的多语言支持)。

 

Spring

 

Spring是轻量级的Java EE应用程序框架。

 

Spring的核心是个轻量级容器(container)，实现了IoC(Inversion of Control)模式的容器，Spring的目标是实现一个全方位的整合框架，在Spring框架下实现多个子框架的组合，这些子框架之间彼此可以独立，也可以使用其它的框架方案加以替代，Spring希望提供one-stop shop的框架整合方案 。

 

Spring不会特別去提出一些子框架来与现有的OpenSource框架竞争，除非它觉得所提出的框架夠新夠好，例如Spring有自己的 MVC框架方案，因为它觉得现有的MVC方案有很多可以改进的地方，但它不强迫您使用它提供的方案，您可以选用您所希望的框架来取代其子框架，例如您仍可以在Spring中整合您的Struts框架 。

 

Spring的核心概念是IoC，IoC的抽象概念是「依赖关系的转移」，像是「高层模组不应该依赖低层模组，而是模组都必须依赖于抽象」是 IoC的一种表现，「实现必须依赖抽象，而不是抽象依赖实现」也是IoC的一种表现，「应用程序不应依赖于容器，而是容器服务于应用程序」也是IoC的一种表现。

 

Spring的架构性的好处

 

Spring能有效地组织你的中间层对象，无论你是否选择使用了EJB。如果你仅仅使用了Struts或其他的包含了Java EE特有APIs的framework，你会发现Spring关注了遗留下的问题。

 

Spring能消除在许多工程上对Singleton的过多使用。根据我的经验，这是一个主要的问题，它减少了系统的可测试性和面向对象特性。

 

Spring能消除使用各种各样格式的属性定制文件的需要，在整个应用和工程中，可通过一种一致的方法来进行配置。曾经感到迷惑，一个特定类要查找迷幻般的属性关键字或系统属性，为此不得不读Javadoc乃至源编码吗？有了Spring，你可很简单地看到类的JavaBean属性。倒置控制的使用(在下面讨论)帮助完成这种简化。Spring能通过接口而不是类促进好的编程习惯，减少编程代价到几乎为零。

 

Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。在Spring应用中的大多数业务对象没有依赖于Spring。

 

使用Spring构建的应用程序易于单元测试。

 

Spring能使EJB的使用成为一个实现选择，而不是应用架构的必然选择。你能选择用POJOs或local EJBs来实现业务接口，却不会影响调用代码。

 

Spring帮助你解决许多问题而无需使用EJB。Spring能提供一种EJB的替换物，它们适于许多web应用。例如，Spring能使用AOP提供声明性事务而不通过使用EJB容器，如果你仅仅需要与单个的数据库打交道，甚至不需要JTA实现。

 

Spring为数据存取提供了一致的框架，不论是使用JDBC或O/R mapping产品(如Hibernate)。

 

Spring确实使你能通过最简单可行的解决办法解决你的问题。这些特性是有很大价值的。

 

Spring能做什么？

 

Spring提供许多功能，在此我将快速地依次展示其各个主要方面。

 

任务描述：

 

首先，让我们明确Spring范围。尽管Spring覆盖了许多方面，但我们已经有清楚的概念，它什么应该涉及和什么不应该涉及。

 

Spring的主要目的是使Java EE易用和促进好编程习惯。

 

Spring不重新开发已有的东西。因此，在Spring中你将发现没有日志记录的包，没有连接池，没有分布事务调度。这些均有开源项目提供(例如 Commons Logging 用来做所有的日志输出，或Commons DBCP用来作数据连接池)，或由你的应用程序服务器提供。因为同样的的原因，我们没有提供O/R mapping层，对此，已有有好的解决办法如Hibernate和JDO。

 

Spring的目标是使已存在的技术更加易用。例如，尽管我们没有底层事务协调处理，但我们提供了一个抽象层覆盖了JTA或任何其他的事务策略。

 

Spring没有直接和其他的开源项目竞争，除非我们感到我们能提供新的一些东西。例如，象许多开发人员，我们从来没有为Struts高兴过，并且感到在MVC web framework中还有改进的余地。在某些领域，例如轻量级的 IoC容器和AOP框架，Spring有直接的竞争，但是在这些领域还没有已经较为流行的解决方案。(Spring在这些区域是开路先锋。)

 

Spring也得益于内在的一致性。

 

所有的开发者都在唱同样的的赞歌，基础想法依然是Expert One-on-One Java EE设计与开发的那些。

 

并且我们已经能够使用一些主要的概念，例如倒置控制，来处理多个领域。

 

Spring在应用服务器之间是可移植的。

 

当然保证可移植性总是一次挑战，但是我们避免任何特定平台或非标准化，并且支持在WebLogic，Tomcat，Resin，JBoss，WebSphere和其他的应用服务器上的用户。

 

Spring的核心即是个IoC/DI的容器，它可以帮程序设计人员完成组件之间的依赖关系注入，使得组件之间的依赖达到最小，进而提高组件的重用性，Spring是个低侵入性(invasive)的框架，Spring中的组件并不会意识到它正置身于Spring中，这使得组件可以轻易的从框架中脱离，而几乎不用任何的修改，反过来说，组件也可以简单的方式加入至框架中，使得组件甚至框架的整合变得容易。

 

Spring最为人重视的另一方面是支持AOP(Aspect-Oriented Programming)，然而AOP框架只是Spring支持的一个子框架，说Spring框架是AOP框架并不是一件适当的描述，人们对于新奇的 AOP关注映射至Spring上，使得人们对于Spring的关注集中在它的AOP框架上，虽然有所误解，但也突显了Spring的另一个令人关注的特色。

 

Spring也提供MVC Web框架的解決方案，但您也可以将自己所熟悉的MVC Web框架与Spring解合，像是Struts、Webwork等等，都可以与Spring整合而成为进用于自己的解決方案。Spring也提供其它方面的整合，像是持久层的整合如JDBC、O/R Mapping工具(Hibernate、iBATIS)、事务处理等等，Spring作了对多方面整合的努力，故说Spring是个全方位的应用程序框架。

 

Hibernate

 

Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了轻量级的对象封装，使得Java程序员可以使用对象编程思维来操纵数据库。Hibernate可以在应用EJB的Java EE架构中取代CMP，完成数据持久化。它还可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用

 

Hibernate的工作方式

 

Hibernate不会对您造成妨碍，也不会强迫您修改对象的行为方式。它们不需要实现任何不可思议的接口以便能够持续存在。惟一需要做的就是创建一份XML“映射文档”，告诉Hibernate您希望能够保存在数据库中的类，以及它们如何关联到该数据库中的表和列，然后就可以要求它以对象的形式获取数据，或者把对象保存为数据。与其他解决方案相比，它几乎已经很完美了。

 

由于本文只是一篇介绍性的文章，所以不会引入构建和使用Hibernate映射文档的具体例子(我在《Hibernate: A Developer's Notebook》一书的头几章中已经介绍了一个例子)。此外，在网上和Hibernate的在线文档中，还可以找到一些不错的例子，请参见下面的“其他信息”部分。它实际上相当直观。应用程序对象中的属性以一种简单而自然的方式与正确的数据库结构相关联。

 

运行时，Hibernate读取映射文档，然后动态构建Java类，以便管理数据库与Java之间的转换。在 Hibernate中有一个简单而直观的API，用于对数据库所表示的对象执行查询。要修改这些对象，(一般情况下)只需在程序中与它们进行交互，然后告诉Hibernate保存修改即可。类似地，创建新对象也很简单;只需以常规方式创建它们，然后告诉Hibernate有关它们的信息，这样就能在数据库中保存它们。

 

Hibernate API学习起来很简单，而且它与程序流的交互相当自然。在适当的位置调用它，就可以达成目的。它带来了很多自动化和代码节省方面的好处，所以花一点时间学习它是值得的。而且还可以获得另一个好处，即代码不用关心要使用的数据库种类(否则的话甚至必须知道)。我所在的公司就曾有过在开发过程后期被迫更换数据库厂商的经历。这会造成巨大的灾难，但是借助于Hibernate，只需要简单地修改Hibernate配置文件即可。

 

这里的讨论假定您已经通过创建Hibernate映射文档，建立了一个关系数据库，并且拥有要映射的Java 类。有一个Hibernate“工具集”可在编译时使用，以支持不同的工作流。例如，如果您已经拥有Java类和映射文档，Hibernate可以为您创建(或更新)必需的数据库表。或者，仅仅从映射文档开始，Hibernate也能够生成数据类。或者，它可以反向设计您的数据库和类，从而拟定映射文档。还有一些用于Eclipse的alpha 插件，它们可以在IDE中提供智能的编辑支持以及对这些工具的图形访问。

 

使用Hibernate的场合

 

既然Hibernate看起来如此灵活好用，为什么还要使用其他的工具呢？下面有一些场景，可以帮助您做出判断(或许通过提供一些比较和上下文，可以有助于鉴别非常适用Hibernate的场合)。

 

如果应用对于数据存储的需要十分简单——例如，您只想管理一组用户优先选择——您根本不需要数据库，更不用说一个优秀的对象-关系映射系统了(即使它也如Hibernate这般易于使用)!从Java 1.4开始，有一个标准的JavaPreferences API可以很好地发挥这个作用。

 

对于熟悉使用关系数据库和了解如何执行完美的SQL查询与企业数据库交互的人来说，Hibernate似乎有些碍手碍脚，这就像带有动力和自动排挡的快艇车会使注重性能的赛车驾驶员不耐烦一样。如果您属于这种人，如果您所在的项目团队拥有一个强大的DBA，或者有一些存储过程要处理，您可能想研究一下iBATIS。Hibernate的创建者本身就把iBATIS当作是另一种有趣的选择。我对它很有兴趣，因为我们曾为一个电子商务站点开发了一个类似的系统(其功能更为强大)，而且从那时到现在，我们已经在其他环境中使用过它，尽管在发现Hibernate之后，在新项目中我们通常更喜欢使用Hibernate。您可以认为，以SQL为中心的解决方案(比如iBATIS)是“反向的”对象/关系映射工具，而 Hibernate是一个更为传统的ORM。

 

当然，还有其他的外部原因会导致采用另外的方法。比如，在一个企业环境中，必须使用成熟的EJB架构(或者其他的一些非普通对象映射系统)。可以为提供自己的数据存储工具的平台量身定做代码，比如Mac OS X's CoreData。使用的可能是像XML DTD这样的存储规范，而它根本不涉及关系数据库。

 

但是，如果您使用的是富对象模型，而且想要灵活、轻松且高效地保存它(无论您是否正要开始或已经决定使用关系数据库，只要这是一个选择——而且存在可用的优秀免费数据库，比如MySQL，或可嵌入Java的HSQLDB，它就应该始终是一个选择)，那么 Hibernate很可能就是您理想的选择。您可能会惊讶于节省的时间之多，以及您将会多么地喜欢使用它。

 

Swing

 

图形用户接口(GUI)库最初的设计目的是让程序员构建一个通用的GUI，使其在所有的平台上都能够正常的显示。但是比较遗憾的是AWT产生的是在各系统看来都同样欠佳的图形用户接口，JAVA1.2为老的java1.0 AWT添加了Java基础类(JFC)，这是一个被称为“Swing”的GUI的一部分。Swing是第二代GUI开发工具集，AWT采用了与特定平台相关的实现，而绝大部分Swing组件却不是。Swing是构筑在AWT上层的一组GUI组件的集合，为了保证可移植性，它完全用Java语言编写，与AWT相比，Swing提供了更完整的组件，引入了许多新的特性和能力。Swing提供了更多的组件库，如：JTable，JTree，Jcombox。Swing也增强了AWT中组件的功能。正是因为Swing具备了如此多的优势所以我们以后在开发中都使用Swing。JComponent类是Swing组件的基类，而JComponent继承自Container类，因此，所有的Swing组件都是AWT的容器。Swing采用了MVC设计模式。