从Servlet到JSP,从Model1到Model2

Servlet的出现

Servlet技术和JSP术是利用Java语言开发Web应用程序的两个主要技术,1996Sun公司首次推出Servlet技术来解决Web程序当中的性能问题。Servlet在首次被用户请求的时候加载到内存当中,之后将一直驻留在内存里,对同一个servlet的后续请求将不用再对这个servlet的类进行实例化,这种机制大大提高了Web应用程序的相应速度。

可是Servlet并不是那么完美,当人们在编写Servlet的时候发现所有HTML输出代码都封装在String对象里,然后再用out对象的print方法向用户展示出来,这不免增加了编码的难度,而且维护起来也十分麻烦,即使稍微一点点的改动也需要重新编译Servlet才行。

JSP以及相关技术的出现

Sun公司意识到了这个问题,并提出了JSP技术。JSP允许Java代码和HTML标签混杂在一起以简化页面的开发,修改页面无需重新编译,当第一次被请求的时候如果原先的JSP有变化则重新自动编译,如果没有变化则直接加载已经存在的实例。

但是问题又接踵而至:

l  Java代码和HTML代码(逻辑和显示)混杂在一起使得程序变得难以阅读和维护

l  把代码放在JSP当中很难重用,这与面向对象的思想是相悖的

l  JSP当中编写代码IDE对此支持的并不是那么十分的出色

l  测试变得困难

逻辑和显示混杂是不被人们所提倡的,早在JSP1.0规范中就鼓励程序员使用JavaBean将业务逻辑代码封装,从而把显示和业务分开。但是事情并不像想象的那么美好,在JSP当中对JavaBean中的方法命名必须遵守其命名约定,所以偶尔会出现某个方法的名字非常冗长难记。为了实现代码和HTML更容易的分离JSP1.1定义了几个自定义标签库,他们比JavaBean更加灵活易用。

但是旧的问题解决了,新的问题出现:自定义标签库很难编写,并且JSP1.1中的自定义标签有着非常复杂的生命周期。

后来人们开始给有关的标签添加一些特定的常用功能。这些标签库编译为几个库文件,统称为JSTLJavaServer Pages Standard Tag LibrariesJSP标准标签库)。

尽管有了JavaBeanJSTL等技术可以把业务逻辑和显示代码分开,但是还是有很多开发者贪图方便或者说目光短浅,仍将逻辑与显示的代码混杂在一起。

Model1设计模型

至此出现了Java语言开发Web应用的第一种设计模型我们称之为Model1,简而言之就是只用JSP不使用Servlet,将页面代码和逻辑代码混杂在一起。从一个JSP页面到另外一个JSP页面是通过页面里的链接完成的。

这种模式的问题就向上面所说的,对于小项目而言开发可能方便了一些。但是对于大型项目,开发是苦不堪言的,因为这种架构不利于网页设计师和Web开发人员之间的劳动分工:开发人员既要参与页面的开发,又要参与业务逻辑的编码。维护起来就更加痛苦了,逻辑与显示代码混杂、页面之间的联系是通过链接(这意味着一旦页面名字改变那么任何使用这个页面的其他页面都要更改,严重的违背了面向对象的思想)这对开发人员来说俨然就是一场噩梦。

Model2设计模型

于是第二种设计模型出现了,我们称之为Model2,这个模型是MVCModel-View-Controller,模型-视图-控制器)设计模式的另一个名字。按照Model2模型开发的应用程序由三种主要部分组成:模型、视图、和控制器。

从Servlet到JSP,从Model1到Model2_第1张图片

Model2模型里,所有的页面都有一个共同的入口点,通常是用一个Servlet或者过滤器(其中Struts1用的是Servlet,而Struts2用的是过滤器)来充当控制器。控制器部分负责接收来自用户输入并控制模型和视图部分做出相应的变化;视图部分负责实现应用程序的信息显示功能;模型部分封装着应用程序的数据和业务逻辑。而在这样的应用程序里,每一个HTTP请求都必须定向到控制器,而潜在各个请求中的URI里的信息将告诉这个控制需要调用哪些动作。控制器检查每个URI以决定应该调用哪些动作。它还将动作对象保存在一个可以从视图访问的地方,这样服务器端的值就可以显示在浏览器上了。最后控制器使用RequestDispatcher对象把请求传递给视图(即相应的JSP页面),再由JSP页面里的定义标签把动作对象的内容显示出来。

整个的发展流程

从Servlet到JSP,从Model1到Model2_第2张图片

原来:技术的发展是由问题堆砌起来的

后面将分别演示用Servlet和过滤器作为控制器实现Model2设计模型,其实可以看作是Struts1Struts2demo

你可能感兴趣的:(servlet)