框架优缺点
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Spring是什么:
Spring是一个轻量级的DI和AOP容器框架。
说它轻量级有一大部分原因是相对与EJB的(虽然本人从没有接触过EJB的应用),重要的是,Spring是非侵入式的,基于spring开发的应用一般不依赖于spring的类。
DI:称作依赖注入(Dependency Injection),和控制反转一个概念,具体的讲,当一个角色需要另外一个角色协助的时候,在传统的程序设计中,通常有调用者来创建被调用者的实例。但是在spring中创建被调用者将不再有调用者完成,因此叫控制反转。创建被调用对象有Spring来完成,在容器实例化对象的时候主动的将被调用者(或者说它的依赖对象)注入给调用对象,因此又叫依赖注入。
AOP:Spring对面向切面编程提供了强有力的支持,通过它让我们将业务逻辑从应用服务(如事务管理)中分离出来,实现了高内聚开发,应用对象只关注业务逻辑,不再负责其它系统问题(如日志、事务等)。Spring支持用户自定义切面。
面向切面编程是面向对象编程的有力补充。面向对象编程将程序分成各个层次的对象,面向切面的程序将运行过程分解成各个切面。AOP是从运行程序的角度去考虑程序的结构,提取业务处理过程的切面,OOP是静态的抽象,AOP是动态的抽象,是对应用执行过程的步骤进行抽象,从而获得步骤之间的逻辑划分。
容器:Spring是个容器,因为它包含并且管理应用对象的生命周期和配置。如对象的创建、销毁、回调等。
框架:Spring作为一个框架,提供了一些基础功能,(如事务管理,持久层集成等),使开发人员更专注于开发应用逻辑。
看完了Spring是什么,再来看看Spring有哪些优点
1.使用Spring的IOC容器,将对象之间的依赖关系交给Spring,降低组件之间的耦合性,让我们更专注于应用逻辑
2.可以提供众多服务,事务管理,WS等。
3.AOP的很好支持,方便面向切面编程。
4.对主流的框架提供了很好的集成支持,如Hibernate,Struts2,JPA等
5.Spring DI机制降低了业务对象替换的复杂性。
6.Spring属于低侵入,代码污染极低。
7.Spring的高度可开放性,并不强制依赖于Spring,开发者可以自由选择Spring部分或全部
Spring MVC 与 Struts2
把这张图放在这里,我是想说SpringMVC和Struts2真的是不一样的,虽然在都有着核心分发器等相同的功能组件(这些由MVC模式本身决定的)。
为什么SpringMVC会赢得最后的胜利呢?谈几点我自己的看法:
第一、MVC框架的出现是为了将URL从HTTP的世界中映射到JAVA世界中,这是MVC 框架的核心功能。而在URL这一点SpringMVC无疑更加优雅。
第二、从设计实现角度来说,我觉得SpringMVC更加清晰。即使我们去对比Struts2的原理图和SpringMVC的类图,它依然很让人困惑,远没有SpringMVC更加直观:
SpringMVC设计思路:将整个处理流程规范化,并把每一个处理步骤分派到不同的组件中进行处理。
这个方案实际上涉及到两个方面:
l 处理流程规范化——将处理流程划分为若干个步骤(任务),并使用一条明确的逻辑主线将所有的步骤串联起来
l 处理流程组件化——将处理流程中的每一个步骤(任务)都定义为接口,并为每个接口赋予不同的实现模式
处理流程规范化是目的,对于处理过程的步骤划分和流程定义则是手段。因而处理流程规范化的首要内容就是考虑一个通用的Servlet响应程序大致应该包含的逻辑步骤:
l 步骤1——对Http请求进行初步处理,查找与之对应的Controller处理类(方法)——HandlerMapping
l 步骤2——调用相应的Controller处理类(方法)完成业务逻
辑——HandlerAdapter
l 步骤3——对Controller处理类(方法)调用时可能发生的异常进行处理——HandlerExceptionResolver
l 步骤4——根据Controller处理类(方法)的调用结果,进行Http响应处理——ViewResolver
正是这基于组件、接口的设计,支持了SpringMVC的另一个特性:行为的可扩展性。
第三、设计原则更加明朗。
【Open for extension /closed for modification】
这条重要的设计原则被写在了Spring官方的reference中SpringMVC章节的起始段:A key design principle in SpringWeb MVC and in Spring in general is the “Open for extension, closed for modification” principle.
并且重点很好地体现在SpringMVC的实现当中,可以扩展,但却不能改变。我曾经扩展过Spring的IOC、AOP功能,这一点SpringMVC应该和Spring一脉相承。
第四、组件化的设计方案和特定的设计原则让SpringMVC形散神聚。
∙神—— SpringMVC总是沿着一条固定的逻辑主线运行
∙形—— SpringMVC却拥有多种不同的行为模式
SpringMVC是一个基于组件的开发框架,组件的不同实现体系构成了“形”;组件的逻辑串联构成了“神”。因此,“形散神不散”:SpringMVC的逻辑主线始终不变,而行为模式却可以多种多样。
第五、更加贴合Web发展的趋势,这个更加虚了,不再展开说这个问题了。
第六、技术上的放缓导致了程序员对Struts2失去了热情,导致SpringMVC依靠自身的努力和Spring的口碑,逐渐显露了自身的优势和特点。
为什么SpringMVC会赢得最后的胜利呢?最后,我们不妨想一想Struts2是怎样流行起来的!
我自己是从Struts1用过来的,后来Struts1的问题很明显了,开源社区出现了很多的MVC 框架,最为突出的是Webwork2。
Webwork2探索了一条与传统Servlet模型不同的解决方案,逐渐被大家熟识和理解,不断发展并得到了广大程序员的认可。它以优秀的设计思想和灵活的实现,吸引了大批的Web 层开发人员投入它的怀抱。
Apache社区与Opensymphony宣布未来的Struts项目将与Webwork2项目合并,并联合推出Struts2。
Struts2能够在一个相当长的时间段内占据开发市场主导地位的重要原因在于其技术上的领先优势。而这一技术上的领先优势,突出表现为对Controller的彻底改造:
public class UserController {
private User user
public String execute() {
// 这里加入业务逻辑代码
return "success";
}
}
从上面的代码中,我们可以看到Webwork2 /Struts2对于Controller最大的改造有两点:
∙在Controller中彻底杜绝引入HttpServletRequest或者HttpServletResponse这样的原生Servlet对象。
∙将请求参数和响应数据都从响应方法中剥离到了Controller中的属性变量。
这两大改造被看作是框架的神来之笔。因为通过这一改造,整个Controller类彻底与Web 容器解耦,可以方便地进行单元测试。而摆脱了Servlet束缚的Controller,也为整个编程模型赋予了全新的定义。从引入新的编程元素的角度来说,Webwork2 / Struts2无疑也是成功的。因为在传统Servlet模式中的禁地Controller中的属性变量被合理利用了起来作为请求处理过程中的数据部分。这样的改造不仅使得表达式引擎能够得到最大限度的发挥,同时使得整个Controller看起来更像是一个POJO。因而,这种表现形态被笔者冠以的名称是:POJO实现模式。POJO实现模式是一种具有革命性意义的模式,因为它能够把解耦合这样