浅谈JavaWeb发展

真的认认真真了解JavaWeb的发展，还是因为突然帮朋友弄个没什么功能的小网站时的突然奇想。但是上来就搭SSM的框架，搭到一半却想起来没什么功能那么麻烦干嘛。干脆不用框架，可是又蒙了，不用框架怎么写。记得用servlet，又忘了怎么用。我想我是不是被框架束缚了？回顾了一下servlet，也回顾了一下JavaWeb发展。

静态页面时代

说道JavaWeb开发的发展历程，就不得不去提起Web的发展历史进程。当然，这些我也是通过资料了解的。网站刚刚发展的时候，全部都是静态的。这里的静态是指全部都是事先编辑好的，不能够更改的。网页难以避免的就是各种各样的请求，这里就提一下当时一个请求是如何返回结果的。例如一张图片，server端的HTTP Server收到请求之后先根据路径查找图片，然后read，再把图片数据发送给客户端，客户端显示。缺点显而易见：访问路径必须是真是存在服务器特定目录，而且动态展示也是做不到的。就像你在博客园发布了一篇文章，想立刻在首页看到是没可能的，只能重新动手编辑首页，加入链接。

CGI时代
 　　静态网站是十分不便的，那么动态展示页面是怎么做到的。CGI就解决了这个问题。
CGI全称是通用网关接口(Common Gateway Interface)，是一种Web应用规范。它是一个可执行的程序或者可运行的脚本，几乎所有的语言都能够写CGI，甚至是Shell。下面一段代码，经过编译成可执行程序后，就是一个CGI。当浏览器发送一个CGI请求后，服务器会启动一个进程运行CGI程序或脚本，由CGI来处理数据，并将结果返回给服务器，服务器再将结果返回给浏览器。例如一个表单，其中action=“***.cgi”。作用是将表单提交的信息直接打印出来。CGI的特点：由Http Server唤起。常见的Http Server如Apache，Lighttpd，nginx都支持CGI。CGI单独启动进程，并且每次调用都会重新启动进程。可以用任何语言编写，只要该语言支持标准输入、输出和环境变量。但是缺点，消耗资源多：每个请求都会启动一个CGI进行，进程消耗资源15M内存的话，同时到达100个请求的话，就会占用1.5G内存。如果请求更多，资源消耗是不可想象的。慢：启动进程本身就慢。每次启动进程都需要重新初始化数据结构等，会变得更慢。（为了解决CGI重复启动进程和初始化的问题，后来还出现了FastCGI，当然也没多快）

Servlet时期
　　CGI的繁荣时期，Java还没有发展起来。当Java开始引领潮流的时候，必然会改进和借鉴之前的设计技术和思想。Servlet就是为了解决CGI的不足。最初
纯Servlet开发，是在Sun公司刚刚推出JavaEE（Java企业版）时，推出了Servlet这个东西。Servlet是实现javax.servlet.Servlet接口的类。一般处理Web请求的Servlet还需要继承javax.servlet.http.HttpServlet。其中，doGet()方法处理GET请求；doPost()方法处理POST请求。在JavaWeb服务中，需要在web.xml中配置映射关系，指定url由谁来处理，同时需要编写一个servlet。（现在在Servlet3.0通常使用@WebServlet注解，不需要web.xml的这部分配置。）这种方式相比于CGI，虽然有了很大的改进，但是对于前端人员来说，这种形式非常非常难以开发和修改。在Servlet中可以通过挨着行输出Html等语句来实现页面的样式和输出，表现、逻辑、控制、业务全部混在Servlet类中，最多把模型层单独写出来。这恐怕是前端工程师的噩梦。

JSP时期-- Servlet的升级
　　经过纯Servlet开发的噩梦之后，Sun公司又推出（或者说是倡导）了JSP技术，全称是Java Server Page，直白的就是可以在HTML中写Java代码。其实原理大致是这样的：Web服务器识别出这是一个对JSP网页的请求并且传递给JSP引擎。通过使用URL或者.jsp文件来完成。JSP引擎从磁盘中载入JSP文件，然后将它们转化为servlet。这种转化只是简单地将所有模板文本改用println()语句，并且将所有的JSP元素转化成Java代码。JSP引擎将servlet编译成可执行类，并且将原始请求传递给servlet引擎。Web服务器的某组件将会调用servlet引擎，然后载入并执行servlet类。在执行过程中，servlet产生HTML格式的输出并将其内嵌于HTTP response中上交给Web服务器。Web服务器以静态HTML网页的形式将HTTP response返回到您的浏览器中。
总之，所有的JSP都会变成对应的Servlet来执行。这样，至少前端工程师能工修改页面了，并且开发比Servlet简单得多。

JSP+JavaBean（Model1开发模式）
　　在HTML代码中写Java代码，方便了前端人员，但是苦了后端人员。因为表现、控制、模型、业务逻辑，依然全部混杂在JSP文件中，大段大段的HTML夹杂着Java的代码，其中还有要做的Web的业务逻辑，这就让人好难过。JSP基础语法中，有一个标签是<jsp:usebean>来实例化对应Bean类的对象，并且可以规定该对象的生命周期（request response session application）
，这样就可以实例化对象，通过实例化对象来进行操作。后来就出现了JSP+JavaBean的模式。JavaBean是一种可重用的Java组件，它可以被Applet、Servlet、SP等Java应用程序调用．也可以可视化地被Java开发工具使用。也逐步有了些分层的意思。JSP：表现层、控制层 。JavaBean：模型层（部分业务逻辑也在JSP）

Servlet+JSP+JavaBean（Model2开发模式-MVC）
　　后来，有牛人发现，Servlet天生非常适合逻辑处理(因为主要是Java代码)，而JSP非常适合页面展示(因为主要是html代码)，那么在结合Servlet和JSP各自的优缺点后，诞生了Web开发中最常用和最重要的架构设计模式：MVC，即模型（Model）、视图（View）和控制器（Controller）。这种开发模式下，JSP页面中就可以不用任何的<%%>语句了，包括<%=%>全部用EL表达式来代替，列表的遍历和条件判断等（Java中的for循环和if语句）也可以通过JSTL来代替。控制层通过Servlet来实现，获取前台传的参数、控制页面跳转，封装对象、向前台传输对象或者参数。 模型层不止可以放JavaBean，还可以再分dao包负责持久层，service包负责业务逻辑层（可有可无）,entity（或者pojo）负责实体类,util负责工具包,等等......MVC模式的项目逻辑也就显而易见了：用户访问JSP页面（视图层），JSP页面向Servlet（控制层）传输参数，Servlet将参数传输（或封装后传输）给相应Service（业务逻辑层），Service调用DAO层（持久层）对应方法，DAO层操作数据库，返回操作结果，Service返回查询结果或操作状态或无返回值，Servlet将查询结果（模型）封装成对象，返回前台（JSP），并且控制页面跳转，JSP回显查询结果或其他信息。
　　简而言之，请求发来后，会首先经过Controller层处理，需要返回的结果封装成对象传递给JSP，然后JSP负责取出数据展示就够了。这样，后端开发人员只负责编写Servlet，前端人员负责JSP，极大提升了开发效率。

框架时期-SSH、SSM
　　有了Servlet和JSP，相当于有了武器。有了MVC，相当于有了战术。但是武器和战术之间还缺少一层，就是具体实施者。单纯使用Servlet、JSP和MVC开发，依然会面临诸多的问题，从而不得不去解决。框架的产生实际上是因为懒，都想着以更简单的方式去解决问题，实际上就是通用问题对应着通用方法。于是就有了现在我们所熟知的，SSH、SSM三大框架组合。无论什么样的框架，本质都是对遇到常见问题的抽象和封装。万变不离其宗，servlet才是真正的根基。我突然理解了上学时，一个老师和我说的不要太执著于框架是什么意思了。就像我们都所熟知的三大框架SSH、SSM，你保证以后不会又出现了新的框架。框架像马鞍，给马套上框架不是为了让马更舒服，而是为了骑马的人更舒服。它，带来最直接只是让开发更简单，让项目变得灵活，同时让coder不要那么灵活。 我们都在用轮子，造车子，然后乘车上路，可也别忘了怎么走路。