框架风云 谈jsf能否拯救web江湖

上传人:第*** 文档编号:32762085 上传时间:2018-02-12 格式:DOC 页数:7 大小:50.50KB
返回 下载 相关 举报
框架风云 谈jsf能否拯救web江湖_第1页
第1页 / 共7页
框架风云 谈jsf能否拯救web江湖_第2页
第2页 / 共7页
框架风云 谈jsf能否拯救web江湖_第3页
第3页 / 共7页
框架风云 谈jsf能否拯救web江湖_第4页
第4页 / 共7页
框架风云 谈jsf能否拯救web江湖_第5页
第5页 / 共7页
点击查看更多>>
资源描述

《框架风云 谈jsf能否拯救web江湖》由会员分享,可在线阅读,更多相关《框架风云 谈jsf能否拯救web江湖(7页珍藏版)》请在金锄头文库上搜索。

1、框架风云 谈 JSF 能否拯救 WEB 江湖 (1) 发布时间:2007.07.06 06:33 来源:赛迪网技术社区 作者:yuanguangdongJava 企业开发可以说是“复杂”的代名词,简化 Java 的开发已经刻不容缓了.随着 JAVA EE 5,JAVA EE6 的相继发布,从老虎到野马,版本更新如此之快,对 SUN 来说是史无前例的。Sun 终于顶不住来自内部改革派和外部竟争者的压力。看来是下定决心简化 JAVA了! 在 2005 年底.Net 2.0 的发布,我们目睹了.Net 2.0 的成功。.Net 2.0 由于开发简单,开发周期短,开发成本低,中小企业纷纷转投向.Net

2、 的怀抱。眼看 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 年发布了第一个

3、 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 后,

4、又在 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 则靠快速开发,方便发布以及依靠在微软的大树下分食中小市场和个人用户。

5、江湖混战,框架兴起 JSP 是一项成功的技术,它功能强大,具有高稳定性和可靠性。但是也就意味着他具有复杂性,难以维护。从它诞生起,人们就一直在努力寻找一种快速的 WEB 开发方案。 在早期,所有的业务方法,数据库连接,访问方法的这些代码都充斥在 JSP 页面里。开发人员既是 UI 设计者又是程序员。同时各种各样的业务代码写进 JSP 页面中,相同的功能代码可能需要编写多次,代码无法重用,如果后期因为业务的变动而进行维护时,对开发人员简直就是一场恶梦。 随后 WEB 开发进入 Model 2 时代,也就是 MVC 模式的应用时代,MVC 模式可以使模型,视图,控制分离出来。通过 Servlet

6、与 JSP 的结合, 由控制器 Servlet 控制请求,调用业务类获得模型数据,并把数据模型展示到相应的视图(JSP)中。这样,业务方法已经从JSP 中分离出来,减少了逻辑代码与 JSP 代码的藕合。JSP 仅仅用于显示数据和提交用户的请求。Servlet 控制用户的请求及调用 Java 类的业务方法, 并对用户的请求进行转发。MVC模式可使得业务方法重用,使得页面开发人员和程序员进行分工。一部分人专注于页面的开发,而一部份人进行业务代码的编写。可以使项目组的人去做他最熟悉的工作。 Model2 的运用,对 WEB 开发带来了一次全新的变革,但是仍然面临着许多问题。有太多的 Servlet

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

8、s 搅乱 WEB 格局 Struts 采用前端控制器模式和 MVC 模式进行设计。强制开发人员以 MVC 的理念来进行 WEB 开发,把表现层与业务层进行分离。Struts 提供了丰富的标签库,在 JSP 1.1 时代,JSP 页面都是通过 JSP 表达式进行编写。虽然采用“”的 JSP 表达式功能非常强大,但是调试十分的麻烦,理解也十分的困难,一般的页面人员几乎无法胜任。而 Struts 此时提供的标签库类似于 HTML 的标记,对开发人员更为友好 ,易于理解和编写。 Struts 提供了一个页面流程控制的功能,而不是把页面的转向写死在代码中。每个请求的页面输入和页面转发都配置在 Strut

9、s-config.xml 中。 Struts 支持自动数据绑定,通过一个 ActionForm 来实现。把页面的数据自动绑定成POJO 对象。并支持数据检验。Struts 提供了国际化的支持,可以很容易的让你的 WEB 系统应用于多种语言版本的要求。 所以 Struts 一推出就受到了开发人员的喜爱,并迅速流行起来。Struts 是目前使用最多,流行时间最长的 JAVA 开源 WEB 框架。 尽管 Struts 取得了成功,但是它仍然有很多的不足。Struts 线程是安全的,但对并发控制是一个问题。在 JSP 2.0 推出 JSTL 后。JSTL 取代 JSP 表达式进行 JSP 编写,JST

10、L 是一种类似 C 语言风格的标记语言。更为人们所熟悉,语法十分简单,明了,功能强大。JSTL 会自动处理 NULL 问题,而不是像 JSP 表达式和 Struts 标签那样遇到 NULL 值是会抛出可恨的异常。相对于优雅的 JSTL,采用 Struts 标签写出的 JSP 代码就像是天书,咒语一样。Struts 大部份标记重复了 JSTL 的相似功能,有一部份与 HTML 重复的标签根本就没有必要存在,还无端的增加了学习和开发的难度。而且 Struts 标签不能良好的处理NULL 问题。 ActionForm 的问题,Struts 通过 ActionForm 来进行数据绑定和数据校验。首先任

11、何需要使用数据绑定和数据校验功能都必须去继承 ActionForm,而 Action Form 又依赖Servlet。这样基于类继承的藕合是没有必要的。数据绑定应该是原始的,就是说页面的数值型数据应该绑定成 Java 类的数值型数据,日期型数据就绑定成日期数据。而 Struts 只能把页面数据绑定成字符型的数据。数据校验应该是具有重用性的,而 Struts 却要把数据检验生硬的写在 ActionForm 中。 同时 Struts 也存在以下几点致命伤: 1、Struts 通过继承具体类来进行扩展,那么你要自定义 Struts 的行为而变得困难。 2、Struts 是不容易测试的,必须通过 St

12、rutsTestCase 来进行辅助测试。而不是真正意义上的单元测试。 3、Struts 太面向 JSP 了,也就是说 Struts 仅支持 JSP,如果我们的应用有些视图不是采用 JSP,而另外一些视图如采用 EXCEL 和 PDF。那么 Struts 是无能为力的。 4、Struts 框架对异常没有提供一个良好的支持。 Struts 也看到了自身存在的缺陷,并不断进行改进,随着 Struts 2 的到来,会带来一些改变的。 WEBwork 是一种比 Struts 更易于使用,基于 Command 模式的开源 WEB 框架。WEBwork 结构十分的简单,也提供了丰富的标签库,WEBwork

13、 的拦截器也十分的优秀。并且 WEBwork 是非线程的。WEBwork 提供了一个 IOC 容器,支持国际化,并且支持多种视图技术。可以说 WEBwork 是一个非常优秀的 WEB 框架。但是 WEBwork 的开发文档少得可怜,它的客户端验证技术不太成熟,Velocity Templates 技术还是太复杂,不提供对组件的封装,而 Struts 的 Tiles 更好一点。采用 WEBwork,必须对它的运行机制十分了解。同时WEBwork 对每个用户交互都强加 Command 模式,而不管是否需要。所有 Command 的excute 方法被迫抛出 Exception,你无法知道哪一命令会

14、抛出什么类型的异常,而且WebWork 的路注定是没有归途的。 Spring Web 框架中一条黑马 2001 年 Rod Johnson 编写一本书叫J2EE 设计开发编程指南。 这本书的内容构成了 Spring 框架的雏形。接着 Rod Johnson 又编写了另外一本书 J2EE without EJB,并同时推出 Spring 框架。这两本书迅速的在业界引起了轰动,为 Spring 的推出作了很好的铺垫。Spring 引入 IOC(控制反转)的概念,采用 POJO 对象,AOP 支持和轻量级容器来开发企业应用,这些正是业界多年来一直苦苦寻找的解决方案。Spring 一推出就红遍了大江南

15、北,迎来了 Java 企业开发的春天。 笔者认为 Spring MVC 是基于请求响应模式最为优秀的开源 WEB 框架。它来自于Spring,天生就支持 IOC 和 AOP,这是其它任何 WEB 框架无法相比的。 Spring MVC 是一个很薄的 WEB 框架,它清晰的分离了数据和视图。支持多种视图技术(JSP,XML,EXCEL, PDF)十分方便。 Spring 的优势 Spring MVC 对于表单提交类的应用提供了一个完整的生命周期。 Spring MVC 支持页面数据的原生绑定为 POJO 对象,并可以自定义扩展绑定器,而不是像 Struts 那样只能把页面数据自动绑定为 Stri

16、ng 类型。 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提供给你真实需要的,通过长期实践证明的东西。 虽然 Spri

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 建筑/环境 > 工程造价

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号