站内搜索: 请输入搜索关键词

当前页面: 开发资料首页JSP 专题我认为JSP有问题

我认为JSP有问题

摘要: jsp 问题 老文

小龙亭主Blueski编译

<table cellSpacing=0 cellPadding=0 width=150 align=right border=0> <tr> <td align=middle bgColor=#cc6633></td></tr> <tr> <td width="100%" bgColor=#000000></td></tr> <tr> <td width="100%" bgColor=#ffffff></td></tr> <tr> <td height=20></td></tr> <tr> <td height=20></td></tr> <tr> <td height=20></td></tr> <tr> <td height=20></td></tr> <tr> <td bgColor=#000000 height=5></td></tr></table>

(编者:这篇文章的原文首次在国外出现时,JSP还只是一种刚刚崭露头角的技术,并没有像现在这样如日中天。现在看来这篇文章的某些观点可能会有一定的局限性,但我不得不承认这是一篇很大气的作品,其中涉及很多JSP的内在原理。因此,我想还是有必要把这篇文章介绍给大家,以便各位从另一个侧面更深入的了解JSP技术。)

如今每一个使用servlets的开发者都知道JSP,一种建构在servlet技术之上的由Sun公司发明并花费大量精力加以推行的web技术。JSP将servlet中的html代码脱离了出来,从而可以加速web应用开发和页面维护。实际上,由Sun发布的官方 "应用开发模型"文档上说得更远:"JSP技术应该被视为标准,而servlets在多数情况下可视为一种补充。"

本文将比较JSP和另一项基于servlets的技术:template engines(模板引擎)。

直接使用Servlets的问题

当Servlets被发明时,整个世界都看到了它的优越性。基于Servlet的动态网页可以被快速执行,可以在多个服务器之间轻易转移, 并且可以和后台数据库完美地集成,因此Servlets被广泛接受成为一种web服务器端的首选平台。

但是,通常通过简单方式即可实现的html代码现在却要让程序员通过 out.println()调用每一行HTML行,这在实际的 Servlet应用中变成一个严重问题。HTML内容不得不通过代码来实现, 这对于大的HTML页来说不啻是一项繁重费时的工作。另外,负责网页内容的人员不得不请开发人员来进行所有的更新。为此,人们寻求这一种更好的解决方式。

JSP诞生

JSP 0.90诞生了。在这种技术中你可以将Java代码嵌入到HTML文件,服务器将自动为页面创建一个Servlet。JSP被认为是一种写Servlet的简易方式。所有HTML可以直接得到而不必通过out.println()调用,而负责页面内容的人员可以直接修改HTML而不必冒破坏Java代码的风险。

但是,让页面美术设计师和开发人员在同一文件上工作并不理想,让Java嵌入HTML被证明是就象将HTML嵌入Java一样令人尴尬。读取一堆很乱的代码仍然是一件困难的事情。

于是,人们在使用jsp方面变得成熟,更多地使用了JavaBeans。Beans包含了jsp所需的业务逻缉代码。JSP中的大多数代码都可以取出来放到bean中去,而只留下极少的标记用于调用bean。

最近,人们开始认为这种方式下的JSP页面真的很象是视图(view)。它们成为一个用于显示客户端请求结果的组件。于是人们会想,为什么不直接对view发送请求呢?目标view如果对该请求不合适又将如何?说到底,很多的请求有嘀挚赡芾慈〉媒峁鹶iew视图。例如,同一请求可能产生成功的页面、数据库例外出错报告,或者是缺少参数的出错报告。同一请求可能产生一个英文页面也可能是西班牙文页面,这取决于客户端的locale。为什么客户端必须直接将请求发送给view?为什么客户端不应该将请求发送给一些通用的服务器组件并让服务器来决定JSP view的返回?

这使很多人接受了已被称为"Model 2"的设计, 这是在JSP 0.92中定义的基于model-view-controller的模型。在这种设计中,请求被发送到一个servlet控制器,它执行了商业逻缉并产生一个相近的数据"model"来用于显示。这一数据随后通过内部送到一个JSP "view"来进行显示,这样看起来JSP页就象是一个普通的嵌入的JavaBean。可以根据负责控制的servlet的内部逻辑来选择适当的JSP页面进行显示。这样,JSP文件成为了一个漂亮的template view。这就是另一种发展,并被另外一些开发者所推崇至今。

进入Template Engines

如果使用template engine来代替通常目的的JSP, 接下去的设计将变得简单,语法更简单,出错信息更易读,工具也更用户化。一些公司已经做了这样的引擎,最著名的可能是WebMacro,他们的引擎是免费的。

开发者应该明了,选定一个template engine来取代JSP提供了以下一些技术优势,而这些同时也正是jsp的不足之处:

使用template engine也有一些问题

JSP的角色

当然,JSP必然会有其地位。即使从名称上也可以看出JSP和ASP的相似性,它们只有一个字母的差别。所以如果要让使用asp的人们转向java,非常相似的jsp环境将对此起到很大的推动作用,和asp保持这种对应关系所能起到的作用应该也是被当时推出jsp的设计者重点考虑到的。

然而这里想要强调的一点是:有利于转入新环境的工作者,和实际上是否使用了该环境的最佳方式,这两者是有很大不同的。

JSP的发展已经日益表明,它正成为最重要的java技术之一,它让人们离开ASP的世界 -- 由此,Sun将支持这一强有力的商业case, Java相关技术支持者也将给予更大力的支持。

然而遗憾的是,其实这并非java平台的最佳解决方案。这将使java解决方案变得好象是没有java的解决方案了。



↑返回目录
前一篇: WebSphere中的Oracle数据源设置------JSP和Oracle数据库的连接
后一篇: Windows2000下整合Mysql4.0.13与Tomcat4.1.24搭建Jsp环境