目录
修炼宝典Servlet+JSP+JavaBean(Model2)
前言
作为没有经历过使用Servlet+JSP+JavaBean+JDBC进行JavaWeb开发的小白程序员,在接触学习Spring时很难体验到Spring带来的便利(不知道为什么要用真的很痛苦)。只知道Spring的两大核心时IOC和AOP,IOC:控制反转,将创建对象的控制器交给Spring管理进行解耦,便于项目的维护和扩展。但是对于没有经历过复杂项目的小白,首先体会不到Spring的优势,其次也好奇如果不使用Spring,JavaWeb是怎么进行开发的呢?本文就从JavaWeb的发展史来介绍为什么会出现Spring,理解了为什么会出现才能更好的理解为什么要设计IOC(主要是学习和梳理知识)。
一、JavaWeb发展历程
没有Servlet的蛮荒纪元
Servlet相信大家都是比较熟悉的(可能有些同学直接学习的SpringMVC,但是还是建议了学习一下Servlet)。这里就从Servlet说起吧。传说在上世纪90年代,因为nternet和浏览器的飞速发展,使得基于浏览器的B/S模式随之火爆发展起来。最初,用户使用浏览器向Web服务器发送的请求都是请求静态资源:HTML、CSS... 但是可以想象:根据用户请求的不同,动态的处理并返回资源是理所当然必须的要求,例如用户提交登录信息,服务器就应该按照提交的数据不同,反馈给用户不同的效果(头像、昵称、地址...)。所以人们非常迫切想要推出一项技术来实现动态的数据交互, Java为了应对上述需求,促进了Servlet技术诞生。
Servlet修炼功法(纯Servlet开发)
SUN公司刚刚推出JavaEE(Java企业版)时,推出了Servlet这个东西,命名就是Service+Applet,即服务小程序。Servlet可以说是Java技术中最早的Web解决方案,Servlet就是普通Java类继承了HttpServlet类,其中HttpServletRequest对象可以获取客户端请求,HttpServletResponse对象可以给客户端响应数据。在Servlet中可以通过Java代码来处理请求、获取数据、响应数据从而实现页面的动态效果(通过HttpServletResponse输出的页面效果可以通过Java代码进行逻辑控制)。但是Servlet宗门的单一斗技存在缺陷:表现、逻辑、控制、业务,全部混在Servlet类中,代码臃肿维护、测试困难。下面给出一个简单例子来直观感受一下。
String username = request.getParameter("username");
String password = request.getParameter("password");
PrintWriter out = response.getWriter();
if(checkUser(username,password)){//逻辑控制
addUser(username,password);//实际业务
out.println("<html>");
out.println("<head><title>Hello World!</title></head>");
out.println("<body>");
out.println("<p>Login Success!</p>");
out.println("</body></html>");//输出表现
}else{
out.println("<html>");
out.println("<head><title>Hello World!</title></head>");
out.println("<body>");
out.println("<p>Error 401 </p>");
out.println("</body></html>");//输出表现
}
}
这样就可以通过用户输入的数据,通过Servlet接收请求、Java代码校验、Servlet响应数据,显示不同的HTML页面及数据。
Servlet功法缺陷
Servlet能够在Java疆域开宗立派,必然是帮助程序员提高了开发JavaWeb界域的速度。但是我们知道Servlet之后又有更多宗门来抢占在Servlet生成HTML页面的方式,那就说明Servlet还存在痛点。从上面代码中我们已经看到Servlet编写HTML是非常的繁琐:
- Servlet代码有大量冗余代码,out输出就得写上百遍;
- 开发Servlet必须精通网页前端和美工,你得非常不直观的在Servlet中写前端代码,这使得实现各种页面效果和风格非常困难(不能所见即所得)。
- 对于后端来说,所有的业务逻辑、页面跳转、样式表现全部混杂在同一个类中,并且一项业务一般只有一个Servlet类与其对应,实在是太麻烦了。
所以为了解决Servlet遗留的这些问题,SUN公司借鉴微软的asp,正式推出了JSP
辅助修炼功法JSP(纯JSP开发时代)
经过纯Servlet开发的黑暗时代,Sun公司又推出了JSP技术,全称是Java Server Page,JSP中采用HTML语言直接生成界面(解决了在Servlet直接编写HTML代码带来的痛苦),还可以在界面中使用<% %>脚本标识嵌入Java代码,揪其本质也是最终生成一个Servlet类来编译解析(JSP底层就是对Servlet的封装)。如果要开发具有大量网页内容的网站,可以先使用网页编辑工具编写网页,然后在网页中嵌入Java代码即可。再来一个简单的例子:
<html>
<head><title>测试</title></head>
<body>
显示的内容是:<% String username= “qiyu” ; out.println(username); %>
</body>
</html>
JSP功法缺陷
虽然JSP可以实现网站的快速开发,但依然存在缺点:网站的输入、输出、处理、控制全部夹杂在一起(JSP中包含大量Java代码,不管是前端程序员还是后端程序员面对JSP都需要看一大堆看不懂的代码,十分痛苦且难以维护),即使只需要修改该页面的一个简单按钮文本,或者一段静态的文本内容,也不得不打开混杂的动态脚本的页面源文件进行修改。当网站中需要进行大量的处理代码的时候,JSP文件将很难维护,并且代码也不容易共享。
- 前端开发人员需要看大量他看不懂的后端代码
- 后端开发人员也在复杂的前端代码中找到能写Java代码的地方
因为JSP在编写网页方面具有优势,而编写处理代码存在很多问题,所以人们把JSP中的处理代码使用JavaBean来实现。于是出现了JSP+JavaBean的开发模式(有人叫做Model1开发模式,为什么这么叫,嗯~~不知道~~~)。
新的修炼方式JSP+JavaBean(Model1)
为了防止走火入魔,这里就要首先弄清楚JavaBean到底是啥?
- 一种JAVA语言写成的可重用组件。为写成JavaBean,类必须是具体的和公共的,并且具有无参数的构造器。
- 通过提供符合一致性设计模式的公共方法将内部域暴露成员属性,set和get方法获取。简单理解为封装的Java类。
这里我理解为JavaBean的出现作为和数据库交互的类,JSP中写部分Java代码用于转发等操作以及HTML页面的生成代码,JavaBean来实现业务逻辑处理和数据库交互。整体结构
修炼宝典Servlet+JSP+JavaBean(Model2)
Model1虽然在一定程度上解耦了,但JSP依旧即要负责页面控制,又要负责逻辑处理,职责不单一!此时Model2应运而生,使得各个部分各司其职,Model2是基于MVC模式的。Model2的开发模式是:Jsp+Servlet+JavaBean的模式,它和Model1不同的是,增加了Servlet。
在这种开发模式下,JSP页面中就可以不用任何的<%%>语句了,包括<%=%>全部用EL表达式来代替,列表的遍历和条件判断等(Java中的for循环和if语句)也可以通过JSTL来代替。 这样的话视图层相比较之前的开发模式来说要薄得多的多,JSP中不涉及任何的业务逻辑,前端人员修改样式也十分方便。这里可以理解为JSP为MVC设计模式中的V,即视图。
控制层通过Servlet来实现,获取前台传的参数、控制页面跳转,封装对象、向前台传输数据。并且可以由自己设计,设法用一个Servlet类实现该模块的所有功能的页面跳转。这里可以理解为Servlet为MVC设计模式中的C,即控制器。
但这里要说明的是Model2并不是一个完全标准的MVC设计模式,因为JavaBean还过于臃肿,并不能完全作为M层存在,所以将JavaBean再一次进行分割:业务逻辑、数据持久化,业务逻辑、数据持久化为MVC设计模式中的M,即模型。
三层架构与MVC设计模式的是是非非
首先讨论一下三层架构和MVC的关系。我们大多数人总会把三层架构和MVC混为一谈,其实并非如此。三层架构是指软件系统的整体设计分层:表现层、业务逻辑层、数据持访问层。MVC设计模式只体现在表现层中,将表现层又分为:模型、视图、控制器。所以在上面Model2模式下对JavaBean分割后形成了三层架构与MVC的全新的JavaWeb开发模式。
三层架构:
- 表现层(UI):通俗说就是用户所能看到的直观的界面。其作用就是接收用户提交的请求数据,以及将程序对用户请求所产生的响应数据反馈给用户。目的就是为用户提供可交互的操作界面。所以,表现层就像已经搭好的积木。
- 业务逻辑层(BLL):简单讲就是“具体问题,具体分析”。它根据用户的不同请求而做出不同响应的处理。可以说是对数据层的一种整合方式。所以,就如同每个人会根据自己的喜好搭建不同的积木一样,业务逻辑层代表的就是搭积木的方式。
- 数据访问层(DAL):它只是提供对数据库操作的多种途径。不同的数据就好比形状各异的积木,而数据访问层就好比取出或放回这些积木的动作。
MVC设计模式:
- 模型(Model):封装的是数据源和所有基于对这些数据的操作。在一个组件中,Model往往表示组件的状态和操作状态的方法,JavaBean处理业务等。
- 视图(View):封装的是对数据源Model的一种显示。一个模型可以由多个视图,而一个视图理论上也可以与不同的模型关联起来,页面显示内容(HTML、CSS)。
- 控制器(Control):封装的是外界作用于模型的操作。通常,这些操作会转发到模型上,并调用模型中相应的一个或者多个方法。一般Controller在Model和View之间起到了沟通的作用,处理用户在View上的输入,并转发给Model。这样Model和View两者之间可以做到松散耦合,甚至可以彼此不知道对方,而由Controller连接起这两个部分,接收请求、控制页面跳转。
至此,页面的表现由JSP实现,转发控制由Servlet实现,业务逻辑写在业务逻辑层,操作数据库部分写在持久化层,分工明确,各司其职。Model1、Model2、三层是在解耦的基础上一步步进化而来,通过解耦我们可以进行进一步的抽象,以应对现实需求的变动。这里要说的就是,从servlet一直到三层架构的转变,其实都是为了实现高内聚,低耦合。一步一步将各个功能分配到不同的地方实现。
二、框架纪元
倡导了MVC思想的JSP+Servlet+JavaBean出现,也存在问题:
- JSP页面中嵌入了很多java代码,使得结构很乱;
- 对于大型项目,Servlet过多,转向频繁,流程,配置等不易集中管理因而出现了struts
框架元祖-struts
2001年6月,struts1.0出现,struts针对JSP推出了一套struts标签,从而使得jsp中没有了Java代码,结构清晰,功能强大。针对servlet,它提供了Action类来代替了Servlet,这个Action类具有Servlet的功能,并且能够进行一些请求过滤和自动转码的功能。
春天来临-Spring
原本已经很完美了,但是又有一个问题,就是我们在Action调用DAO、JavaBean等对象的时候都需要在自身代码中构建它们的对象来使用,这样增加了程序的耦合性,这与我们:“高内聚、松耦合”的思想不符合,那么怎么解决这个问题呢?因而出现了Spring框架。
Spring框架有两大功能:IOC(控制反转)和 AOP(面向切面的编程)
- IOC就是说:当一个类中想要调用另外一个类的对象时,不需要再通过new 关键字来创建,而是由Spring框架来负责:创建、分配和管理,从而降低了程序中的耦合性,程序控制创建对象
- AOP可以用来做一些日志的打印和输出,用于提示程序执行过程中的一些具体信息等,不改动源代码的情况下新增功能。
保住头发-SpringMVC
struts和Spring的整合,由于每一个JavaBean都要在Spring中注册,每一个URL都要在struts配置文件中配置。当JavaBean很多和URL对应的请求很多的时候,配置文件无疑会是很庞大的,这个就会使得配置起来很麻烦的费力。那么还有没有更好的办法使得能够结合Spring的功能和struts的功能,但是又可以使配置文件不会批量的增加?因而SpringMVC出现了
SpringMVC通过“基于注解”的方式代替了struts,并且通过Controller类来代替和实现了Action的功能。由于是基于注解的,所以很多的配置信息放在了Controller类中配置,从而降低了.xml文件的配置复杂度。
总结
通说上述对JavaWeb发展历程的梳理,对于没有经历过“蛮荒纪元”的程序小白来说,能够对各个阶段,各个框架产生的原因及主要作用有初步的了解。在后续的学习过程中可以抓住框架学习的重点(也终于让我明白了为什么会有Spring框架)。
至此鸣谢:https://blog.csdn.net/liuyaguang0606/article/details/113249090