细说框架风云 JSF能否拯救WEB江湖

细说框架风云 JSF能否拯救WEB江湖

细说框架风云 JSF能否拯救WEB江湖

 
来源：IT168  2008-08-26 作者：袁光东
 
Java企业开发可以说是“复杂”的代名词,简化Java的开发已经刻不容缓了.随着JAVA EE 5，JAVA EE6的相继发布，从老虎到野马，版本更新如此之快，对SUN来说是史无前例的。Sun终于顶不住来自内部改革派和外部竟争者的压力。看来是下定决心简化JAVA了！

在2005年底.Net 2.0的发布，我们目睹了.Net 2.0的成功。.Net 2.0由于开发简单，开发周期短，开发成本低，中小企业纷纷转投向.Net的怀抱。眼看JAVA EE的市场慢慢的被.Net蚕食，Sun是急在眼里，痛在心里。

JSF也随之成为JAVA EE的规范，Java EE 6明显加强对JAVA开发桌面应用的支持，Sun也想让JAVA在桌面开发中占有一席之地。而把JSF作为强制规范，是想通过JSF来继续统领WEB 开发来固守企业应用的市场，2007年，Sun想通过JSF来打一个翻身仗。

WEB江湖

自Java 1995年面世后，Sun靠Applet 抢占了WEB前端市场，而Flash的出现却让Applet早早退出历史舞台。于是Sun在1997年发布了第一个WEB服务器（Java WEB Server）及应用的Servlet API。Servlet可以通过纯Java语言来编写企业WEB应用，Servlet从厂商急需角度出发，迅速的成为了企业应用解决方案的标准。

虽然Servlet通过Java这种高级语言来进行编写，而最终是展示给用户的。需要有良好的用户界面。这就需要支持HTML等WEB脚本。可是Servlet却不能良好的嵌入HTML等前端代码，开发起来非常复杂。

终于在1998年，Sun推出了JSP。而此时，与之相似的ASP已经发布了两年之久。
Sun在1999年初推出JSP 1.0后，又在1999年11月推出JSP 1.1，Sun终于凭借Servlet和JSP技术，迅速的占领了绝大部份的企业市场份额。在2002年4月，JSP发展到1.2版本。到2003年Sun推出JSP 2.0，同时推出的JSTL(JAVA 标准标记语言)取代JSP表达式的弱点，更进一步简化JSP的编写。 JSP慢慢变成一种非常成熟的WEB技术，JSP凭借其技术成熟，稳定，及Java的强大功能和跨平台能力成为WEB企业应用的王者，占领了80%以上的企业应用市场。而ASP则靠快速开发，方便发布以及依靠在微软的大树下分食中小市场和个人用户。

江湖混战,框架兴起

JSP是一项成功的技术，它功能强大，具有高稳定性和可靠性。但是也就意味着他具有复杂性，难以维护。从它诞生起，人们就一直在努力寻找一种快速的WEB开发方案。

在早期，所有的业务方法，数据库连接，访问方法的这些代码都充斥在JSP页面里。开发人员既是UI设计者又是程序员。同时各种各样的业务代码写进JSP页面中，相同的功能代码可能需要编写多次，代码无法重用，如果后期因为业务的变动而进行维护时，对开发人员简直就是一场恶梦。

随后WEB开发进入Model 2时代，也就是MVC模式的应用时代，MVC模式可以使模型，视图，控制分离出来。通过Servlet与JSP的结合,由控制器Servlet控制请求，调用业务类获得模型数据，并把数据模型展示到相应的视图(JSP)中。这样，业务方法已经从JSP中分离出来，减少了逻辑代码与JSP代码的藕合。JSP仅仅用于显示数据和提交用户的请求。Servlet控制用户的请求及调用Java类的业务方法,并对用户的请求进行转发。MVC模式可使得业务方法重用，使得页面开发人员和程序员进行分工。一部分人专注于页面的开发，而一部份人进行业务代码的编写。可以使项目组的人去做他最熟悉的工作。

Model2的运用，对WEB开发带来了一次全新的变革，但是仍然面临着许多问题。有太多的Servlet类，一个请求对应着一个Servlet类。页面流程的控制全部通过硬代码写死在Servlet类中，每一个Servlet类都需要在WEB.XML中进行配置，不能很好的支持国际化等。后来人们通过前端控制器模式来解决了这样问题，就是由一个Servlet来响应所有的请求。根据不同的请求参数来调用不同的服务方法。这样有效的减少了Servlet类。几乎现在所有的WEB框架都是采用前端控制器和MVC模式的运用。在这样的背景下，WEB框架应运而生，Struts最先面世，WEBWork等纷纷涌现。开发者采用框架大大的简化了WEB应用的开发，加快了开发的速度和质量。

Struts搅乱WEB格局

Struts采用前端控制器模式和MVC模式进行设计。强制开发人员以MVC的理念来进行WEB开发，把表现层与业务层进行分离。Struts提供了丰富的标签库，在JSP 1.1时代，JSP页面都是通过JSP表达式进行编写。虽然采用“<%%>”的JSP表达式功能非常强大，但是调试十分的麻烦，理解也十分的困难，一般的页面人员几乎无法胜任。而Struts此时提供的标签库类似于HTML的标记，对开发人员更为友好,易于理解和编写。

Struts提供了一个页面流程控制的功能，而不是把页面的转向写死在代码中。每个请求的页面输入和页面转发都配置在Struts-config.xml中。

Struts支持自动数据绑定，通过一个ActionForm来实现。把页面的数据自动绑定成POJO对象。并支持数据检验。Struts 提供了国际化的支持，可以很容易的让你的WEB系统应用于多种语言版本的要求。

所以Struts一推出就受到了开发人员的喜爱，并迅速流行起来。Struts是目前使用最多,流行时间最长的JAVA开源 WEB框架。

尽管Struts取得了成功，但是它仍然有很多的不足。Struts线程是安全的，但对并发控制是一个问题。在JSP 2.0推出JSTL后。JSTL取代JSP表达式进行JSP编写，JSTL是一种类似C语言风格的标记语言。更为人们所熟悉，语法十分简单，明了,功能强大。JSTL会自动处理NULL问题，而不是像JSP表达式和Struts标签那样遇到NULL值是会抛出可恨的异常。相对于优雅的JSTL，采用Struts标签写出的JSP代码就像是天书，咒语一样。Struts大部份标记重复了JSTL的相似功能，有一部份与HTML重复的标签根本就没有必要存在，还无端的增加了学习和开发的难度。而且Struts标签不能良好的处理NULL问题。

ActionForm的问题，Struts通过ActionForm来进行数据绑定和数据校验。首先任何需要使用数据绑定和数据校验功能都必须去继承ActionForm，而Action Form又依赖Servlet。这样基于类继承的藕合是没有必要的。数据绑定应该是原始的，就是说页面的数值型数据应该绑定成Java类的数值型数据，日期型数据就绑定成日期数据。而Struts只能把页面数据绑定成字符型的数据。数据校验应该是具有重用性的，而Struts却要把数据检验生硬的写在ActionForm中。
同时Struts也存在以下几点致命伤：

1、Struts通过继承具体类来进行扩展，那么你要自定义Struts的行为而变得困难。

2、Struts是不容易测试的，必须通过StrutsTestCase来进行辅助测试。而不是真正意义上的单元测试。

3、Struts太面向JSP了，也就是说Struts仅支持JSP，如果我们的应用有些视图不是采用JSP，而另外一些视图如采用EXCEL和PDF。那么Struts是无能为力的。

4、Struts框架对异常没有提供一个良好的支持。

Struts也看到了自身存在的缺陷，并不断进行改进，随着Struts 2的到来，会带来一些改变的。

WEBwork是一种比Struts更易于使用，基于Command模式的开源WEB框架。WEBwork结构十分的简单，也提供了丰富的标签库，WEBwork的拦截器也十分的优秀。并且WEBwork是非线程的。WEBwork提供了一个IOC容器，支持国际化，并且支持多种视图技术。可以说WEBwork是一个非常优秀的WEB框架。但是WEBwork的开发文档少得可怜,它的客户端验证技术不太成熟，Velocity Templates技术还是太复杂，不提供对组件的封装,而Struts的Tiles更好一点。采用WEBwork，必须对它的运行机制十分了解。同时WEBwork对每个用户交互都强加Command模式，而不管是否需要。所有Command 的excute方法被迫抛出Exception，你无法知道哪一命令会抛出什么类型的异常，而且WebWork的路注定是没有归途的。

Spring Web框架中一条黑马

2001年Rod Johnson编写一本书叫《J2EE设计开发编程指南》。 这本书的内容构成了Spring框架的雏形。接着Rod Johnson又编写了另外一本书《J2EE without EJB》,并同时推出Spring框架。这两本书迅速的在业界引起了轰动，为Spring的推出作了很好的铺垫。Spring引入IOC（控制反转）的概念，采用POJO对象，AOP支持和轻量级容器来开发企业应用，这些正是业界多年来一直苦苦寻找的解决方案。Spring一推出就红遍了大江南北，迎来了Java企业开发的春天。

笔者认为Spring MVC 是基于请求响应模式最为优秀的开源WEB框架。它来自于Spring，天生就支持IOC 和AOP，这是其它任何WEB框架无法相比的。

Spring MVC 是一个很薄的WEB框架，它清晰的分离了数据和视图。支持多种视图技术(JSP,XML,EXCEL, PDF…)十分方便。

Spring的优势

Spring MVC对于表单提交类的应用提供了一个完整的生命周期。

Spring MVC 支持页面数据的原生绑定为POJO对象，并可以自定义扩展绑定器，而不是像Struts那样只能把页面数据自动绑定为String 类型。

Spring MVC 自定义行为变得十分容易，这得益于Spring框架良好的设计，Spring MVC的控制器也是基于Command模式的。

Spring MVC 有良好的数据校验框架，也很容易自定义数据校验行为。

Spring MVC 提供了一个良好的异常处理机制，可以方便的自定义各类异常的处理行为。

Spring MVC 提供了有用的标签。（注意是有用的，没有用的Spring绝不提供）

Spring MVC 支持I18N及文件上传等。

Spring 还推出了Spring WEB Flow,用于向导式的WEB应用开发。

Rod Johnson 是一个JAVA EE专家，我更愿意称他为一个实践家。Rod Johnson 的经典语录是“不要重复发明轮子”，Spring 框架的各方面应用都来源于长期的实践经验，集百家之长，吸收其它框架的精华,正是Spring取得成功的原因。Spring MVC也是如此。Spring提供给你真实需要的，通过长期实践证明的东西。

虽然Spring 已经大红大紫了，但是Spring MVC却没有流行起来。它出来太晚了，而Struts已经深入人心了，Struts这么多年的表现一直不错，虽然Struts并不是那么优秀。但是它有着庞大的开发人群，关于Struts的资料是铺天盖地。企业很容易找到Struts开发人员,却难以找到Spring MVC开发人员。另外一个客观原因就是Spring太灵活了，Spring MVC也不例外，正因为Spring MVC过于灵活，致使初学者望而生畏。Spring MVC需要进行过多的XML配置,Spring MVC的文档相对比较少，所以现在Spring MVC的使用者有限，但无论如何，Spring MVC是一个非常优雅的WEB开发框架，花费一点学习成本是值得的。

ASP.Net的成功说明了什么？

ASP.Net是一种面向组件，基于事件驱动模型的WEB开发技术。在基于请求驱动模型的WEB开发技术中(如JSP和ASP)，程序代码需要混合在HTML标签中。而事件驱动模型与请求驱动模型相比，在一个表单上的组件通过激活应用程序的事件来响应用户的行动。开发人员通过为组件的相关事件编写相应的程序代码来实现相关的逻辑。事件驱动模型的WEB开发技术提供了一种更为直观的编程模式，使得WEB开发就像编写一个VB或Java Swing桌面应用程序一样。用鼠标把相应的控件拖到页面视图，然后再为控件编写相应的事件代码来实现业务逻辑。这样，就把WEB前端开发变成了运用高级语言进行程序开发(在ASP.NET中采用VB..NET或C#)。面向组件和基于事件驱动模型使得WEB开发真正的回归到了传统的开发方式。大大的简化了WEB项目开发的复杂度。

ASP.NET提供了丰富有WEB前端组件。因为ASP.Net是面向组件的，和基于事件的。所以ASP.Net必须提供丰富的组件，并为这些组件定义相关的事件。让开发人员去扩展事件代码来完成逻辑功能。ASP.NET 一开始就提供最实用的WEB组件，如DataGrid用于数据显示，开发人员只需要通过设置属性就可以实现自定义分页显示。而在以前的ASP或JSP则需要编写大量的程序代码才能完成。到ASP.NET 2.0时，微软更是提供了近150多个WEB组件，如在WEB开发中经常用到的树形菜单组件，下拉菜单组件，文件上传组件等。ASP.NET通过提供这些丰富而功能强大的组件，使得WEB应用开发就像桌面应开发一样简单。

正因为ASP.Net带来了一种全新的开发模式，使得以往复杂的WEB应用开发变得简单，让WEB应用更易于发布，并通过微软的商业运作，ASP.NET一扫ASP的阴霏，迅速的占据了大量企业市场份额。
ASP.NET的成功对我们有什么启示呢？可以肯定面向组件、基于事件驱动模型是未来WEB开发技术的发展方向。ASP,JSP等基于请求驱动式的WEB技术必将退出历史的舞台。

因为由厂商来提供丰富而实用的组件，大大简化WEB前端的开发量和开发难度。把复杂的问题交由厂商或开源组织去解决。基于事件驱动模型才是真正的把UI人员和业务程序员分离开来。只有把程序代码与HTML标记分离，才能真正做到UI设计者与程序员分离。

面向组件，基于事件驱动的WEB框架要取得成功必须提供大量实用的WEB组件。只有提供了丰富的，功能强大的WEB组件，开发人员才能从WEB开发中解脱出来。否则如果每个用户都需要去实现自己的组件库，那样的工作量也是非常庞大的。特别是针对一些小型用户。必须要有优秀的IDE工具配套支持，如果没有VS 2003或VS2005开发工具，而是通过简单的文本编辑工具来进行ASP.Net开发，很难想像ASP.Net会成功。要真正的实现像VB或Java Swing编写桌面应用程序那样来开发WEB应用程序，优秀的IDE工具是必不可少的。允许你把组件从组件面板拖放到页面上并通过属性编辑器来定义它的外观和行为，直接为组件的相关事件编写事件代码。

JSF及它的未来

Java Server Faces 简称JSF,是一种面向组件和事件驱动模型的WEB开发技术。JSF的诞生还要追溯到2001年。在2001年5月,Sun制定了一个用户界面框架的规范JSR#127.

而JSF 规范的1.0到2004年3月才得以面世。直到JAVA EE 5的发布，JSF推出1.2版本并作为JAVA EE 5的一部分同时发布。历经5年的风雨，JSF现在成为了JAVA企业应用规范的一部份。

我在上节讨论ASP.NET的成功时，已经介绍了面向组件，基于事件驱动模型的WEB开发技术的优势。并从ASP.NET的成功可以看出面向组件和基于事件驱动模型是未来WEB技术的发展方向。

从技术上来看JSF是非常先进的，提供了很多复杂的组件支持类似Spring的依赖注入功能。页面流程控制也通过Faces-config.XML来配置，而不是写死在代码里。这有点与Struts类似。同时像SUN，Oracle,Boland,IBM等公司都为JSF提供了开发环境，Sun的Java Studio Creator2 和Oracle的Oralce Jdeveloper 10g都是免费的JSF开发工具,像Eclipse也有相应的插件提供对JSF的支持。JSF技术也同时得到了许多厂商的支持，如Sun的JSF WEB UI,IBM的JSF extension,Oracle的ADF Faces.还有许多开源项目如My Faces都提供了对JSF的支持和扩展。

这样看来，JSF成为了JAVA EE的标准，又得到了众多厂商和组织的支持，那么JSF应该是前途一片光明啦?

何以见得，JSF错过了它的最好发展时期。Sun其实很早之前就想简化JSP的开发，用一种新的技术来取代JSP。从而简化整个WEB层的开发。于是在2001年就开始制定了JSF的规范，但是由于SUN的官僚作风及商业推广的失败，JSF一直未能走向前台。如果SUN能在2002年或2003年，在JSP最红火的时候全力推出JSF。取名为JSP 2.0或JSP 3.0。而不是一意孤行的取名为JSF，那么现在JAVA的WEB开发早已经是面向组件和基于事件驱动了。

成熟和稳定方面：

JSP的确是一种非常成熟和稳定的技术，就是因为JSP太成熟了，所以才导致了JSF的发展缓慢。世界上有太多采用JSP技术的成功案例，SUN非要把JSF变成一个新生儿，谁也不愿意去冒这个风险。虽然采用JSP技术进行WEB开发是复杂的，而且开发周期要长，但是它是稳定并且成熟的WEB技术。JSP已经占据了大量的市场份额，如果JSF要想取代JSP，那么JSF就必须有成功的案例来证明JSF能像JSP那样可靠和稳定。

厂商的支持方面：

厂商对JSF的支持远远不够。从JSF1.0，到JSF1.2的发布并成为JAVA EE的标准，经历了近五年的时间。各个厂商一直对JSF持观望的态度，其实主要还是取决于SUN。如果SUN在早期就把JSF作为JAVA EE的标准，那么现在JSF已经是遍地开花了。JSF的命运从一开始就像EJB，在实验室时呆了5年之久，要把它定制成一个大而全的规范是不可能的，任何技术都应该听取开发人员的意见，EJB的失败已经充分的证明了在办公室写出的规范并不是开发人员所需要的。
虽然IBM，Oracle等厂商现在都已经提供了对JSF的支持，但是他们提供的JSF组件库都非常有限，而且有些组件是已经过时的组件。同ASP.NET 2.0相比，各厂商对JSF的支持远远不够，这又怎么能够吸引开发者和企业选择JSF呢？同时，ASP.NET 2.0定义的页面的生命周期要比JSF灵活及有用得多。而JSF的生命周期则显得生硬和呆板。

我们上节说到ASP.NET的成功离不开VS 2003和VS 2005这些优秀的IDE开发工具的支持。虽然有Sun的Java Studio Creator2 和Oracle的Oralce Jdeveloper 10g免费支持JSF开发，但它们都不是最主流的JAVA 企业应用开发工具。而像目前最主流的ECLIPSE却没有很好的支持JSF的开源免费插件。在开源的大旗下，恐怕很少有人会再去选择收费的开发工具吧。WEB开发只是JAVA企业应用开发的一部份，而不是全部。希望哪一天能见到Sun或IBM这样的商业公司来为ECLIPSE这些主流IDE开发支持JSF的插件。其实世面上还有一些专门针对JSF的开发工具，但是我们要知道，JSF仅仅是JAVA企业应用开发的一部份，我们更需要一个成熟的集成开发环境，如重构，单元测试，甚至整个项目的生命周期管理。我们需要的是在一个主流的成熟的集成开发环境上提供对JSF的支持，而不是那些的专门针对JSF的单一编辑工具。

Sun商业策略方面：

SUN的商业推广策略也是JSF能否成功的关键。SUN不缺技术，但是缺商业推广。JSF迟迟未能成为JAVA EE的标准，延误了JSF的推广。把JSF取名为JSP 3.0都可能对JSF发展更为有利。很多时机被SUN一再错过了，才让JSF在今天显得如此的尴尬。JSF社区的建设及该如何吸引开发人员和企业转向JSF？SUN的商业推广策略是至关重要的。

天将降大任于斯JSF也！！！虽然WEB开发技术注定要进入面向组件和基于事件驱动的时代， JSF 能否拯救WEB的江湖呢？让我们共同拭目以待吧！！