Spring是一个开源框架,Spring是于2003 年兴起的一个轻量级的Java 开发框架,由Rod Johnson 在其著作Expert One-On-One J2EE Development and Design中阐述的部分理念和原型衍生而来。它是为了解决企业应用开发的复杂性而创建的。框架的主要优势之一就是其分层架构,分层架构允许使用者选择使用哪一个组件,同时为 J2EE 应用程序开发提供集成的框架。Spring使用基本的JavaBean来完成以前只可能由EJB完成的事情。然而,Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度而言,任何Java应用都可以从Spring中受益。Spring的核心是控制反转(IoC)和面向切面(AOP)。简单来说,Spring是一个分层的JavaSE/EEfull-stack(一站式) 轻量级开源框架。

特点:

1.方便解耦,简化开发
通过Spring提供的IoC容器,我们可以将对象之间的依赖关系交由Spring进行控制,避免硬编码所造成的过度程序耦合。有了Spring,用户不必再为单实例模式类、属性文件解析等这些很底层的需求编写代码,可以更专注于上层的应用。
2.AOP编程的支持
通过Spring提供的AOP功能,方便进行面向切面的编程,许多不容易用传统OOP实现的功能可以通过AOP轻松应付。
3.声明事物的支持
在Spring中,我们可以从单调烦闷的事务管理代码中解脱出来,通过声明式方式灵活地进行事务的管理,提高开发效率和质量。
4.方便程序的测试
可以用非容器依赖的编程方式进行几乎所有的测试工作,在Spring里,测试不再是昂贵的操作,而是随手可做的事情。例如:Spring对Junit4支持,可以通过注解方便的测试Spring程序。
5.方便集成各种优秀框架
Spring不排斥各种优秀的开源框架,相反,Spring可以降低各种框架的使用难度,Spring提供了对各种优秀框架(如Struts,Hibernate、Hessian、Quartz)等的直接支持。
6.降低Java EE API的使用难度
Spring对很多难用的Java EE API(如JDBC,JavaMail,远程调用等)提供了一个薄薄的封装层,通过Spring的简易封装,这些Java EE API的使用难度大为降低。
7.Java 源码是经典学习范例
Spring的源码设计精妙、结构清晰、匠心独用,处处体现着大师对Java设计模式灵活运用以及对Java技术的高深造诣。Spring框架源码无疑是Java技术的最佳实践范例。如果想在短时间内迅速提高自己的Java技术水平和应用开发水平,学习和研究Spring源码将会使你收到意想不到的效果。
好处:
在我们进入细节以前,让我们看一下Spring可以给一个工程带来的一些好处:
Spring能有效地组织你的中间层对象,无论你是否选择使用了EJB。如果你仅仅使用了Struts或其他的包含了J2EE特有APIs的framework,你会发现Spring关注了遗留下的问题。Spring能消除在许多工程上对Singleton的过多使用。根据我的经验,这是一个主要的问题,它减少了系统的可测试性和面向对象特性。
Spring能消除使用各种各样格式的属性定制文件的需要,在整个应用和工程中,可通过一种一致的方法来进行配置。曾经感到迷惑,一个特定类要查找迷幻般的属性关键字或系统属性,为此不得不读Javadoc乃至源编码吗?有了Spring,你可很简单地看到类的JavaBean属性。倒置控制的使用(在下面讨论)帮助完成这种简化。
Spring能通过接口而不是类促进好的编程习惯,减少编程代价到几乎为零。
Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。在Spring应用中的大多数业务对象没有依赖于Spring。
使用Spring构建的应用程序易于单元测试。
Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。你能选择用POJOs或local EJBs来实现业务接口,却不会影响调用代码。
Spring帮助你解决许多问题而无需使用EJB。Spring能提供一种EJB的替换物,它们适于许多web应用。例如,Spring能使用AOP提供声明性事务而不通过使用EJB容器,如果你仅仅需要与单个的数据库打交道,甚至不需要JTA实现。
Spring为数据存取提供了一致的框架,不论是使用JDBC或O/R mapping产品(如Hibernate)。
Spring确实使你能通过最简单可行的解决办法解决你的问题。这些特性是有很大价值的。
总结起来,Spring有如下优点:
1.低侵入式设计,代码污染极低
2.独立于各种应用服务器,基于Spring框架的应用,可以真正实现Write Once,Run Anywhere的承诺
3.Spring的DI机制降低了业务对象替换的复杂性,提高了组件之间的解耦
4.Spring的AOP支持允许将一些通用任务如安全、事务、日志等进行集中式管理,从而提供了更好的复用
5.Spring的ORM和DAO提供了与第三方持久层框架的良好整合,并简化了底层的数据库访问
6.Spring并不强制应用完全依赖于Spring,开发者可自由选用Spring框架的部分或全部
简单理解
一.概念:
1. spring是开源的轻量级框架

2 spring核心主要两部分:

(1)aop:面向切面编程,扩展功能不修改源代码实现,详解【http://www.cnblogs.com/landeanfen/p/4782370.html】

(2)ioc:控制反转

比如有一个类,在类里面有方法(不是静态的方法),调用类里面的方法,创建类的对象,使用对象调用方法,创建类对象的过程,需要new出来对象, 把对象的创建不是通过new方式实现,而是交给spring配置创建类对象。

我用通俗的话给你解释把。首先你不用框架不是每次创建对象都要用关键字“new”呢?对吧。有了spring配置就不用new了,直接拿。举个例子:假如你吃饭,每次你要吃饭时都要自己准备碗和筷子,每次都要自己准备,用了框架后,再 吃饭你只要吃就行了,就不用准备碗和筷子了因为spring已经给你准备好了。这样是不是很方便。
    spring主要就是不用你自己创建对象,都配置在配置文件中。如果你写好一个项目,你再a类中创建了b类的方法,c类也创建了b类的方法,如果那天要改b类的类名,你就要在a和c中都改,如果有100个类都用了b类呢?那你不是要改死哦!!
如果用了spring,你只要修改配置文件一个位置就好了,是不是很方便维护呢。所以,小项目用不着spring框架。手打好累。。。
ioc:控制反转
    ioc的思想最核心的地方在于,资源不由使用资源的双方管理,而由不使用资源的第三方管理,这可以带来很多好处。第一,资源集中管理,实现资源的可配置和易管理。第二,降低了使用资源双方的依赖程度,也就是我们说的耦合度。

也就是说,甲方要达成某种目的不需要直接依赖乙方,它只需要达到的目的告诉第三方机构就可以了,比如甲方需要一双袜子,而乙方它卖一双袜子,它要把袜子卖出去,并不需要自己去直接找到一个卖家来完成袜子的卖出。它也只需要找第三方,告诉别人我要卖一双袜子。这下好了,甲乙双方进行交易活动,都不需要自己直接去找卖家,相当于程序内部开放接口,卖家由第三方作为参数传入。甲乙互相不依赖,而且只有在进行交易活动的时候,甲才和乙产生联系。反之亦然。这样做什么好处么呢,甲乙可以在对方不真实存在的情况下独立存在,而且保证不交易时候无联系,想交易的时候可以很容易的产生联系。甲乙交易活动不需要双方见面,避免了双方的互不信任造成交易失败的问题。因为交易由第三方来负责联系,而且甲乙都认为第三方可靠。那么交易就能很可靠很灵活的产生和进行了。

这就是ioc的核心思想。生活中这种例子比比皆是,支付宝在整个淘宝体系里就是庞大的ioc容器,交易双方之外的第三方,提供可靠性可依赖可灵活变更交易方的资源管理中心。另外人事代理也是,雇佣机构和个人之外的第三方。

控制反转( Inversion of Control ), 我觉得有必要先了解软件设计的一个重要思想:依赖倒置原则(Dependency Inversion Principle )。

什么是依赖倒置原则?假设我们设计一辆汽车:先设计轮子,然后根据轮子大小设计底盘,接着根据底盘设计车身,最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系:汽车依赖车身,车身依赖底盘,底盘依赖轮子。

<img src="https://pic4.zhimg.com/50/v2-c68248bb5d9b4d64d22600571e996446_hd.jpg" data-caption="" data-rawwidth="1562" data-rawheight="186" class="origin_image zh-lightbox-thumb" width="1562" data-original="https://pic4.zhimg.com/v2-c68248bb5d9b4d64d22600571e996446_r.jpg"> 
这样的设计看起来没问题,但是可维护性却很低。假设设计完工之后,上司却突然说根据市场需求的变动,要我们把车子的轮子设计都改大一码。这下我们就蛋疼了:因为我们是根据轮子的尺寸设计的底盘,轮子的尺寸一改,底盘的设计就得修改;同样因为我们是根据底盘设计的车身,那么车身也得改,同理汽车设计也得改——整个设计几乎都得改!

我们现在换一种思路。我们先设计汽车的大概样子,然后根据汽车的样子来设计车身,根据车身来设计底盘,最后根据底盘来设计轮子。这时候,依赖关系就倒置过来了:轮子依赖底盘, 底盘依赖车身, 车身依赖汽车。

<img src="https://pic1.zhimg.com/50/v2-e64bf72c5c04412f626b21753aa9e1a1_hd.jpg" data-caption="" data-rawwidth="1504" data-rawheight="190" class="origin_image zh-lightbox-thumb" width="1504" data-original="https://pic1.zhimg.com/v2-e64bf72c5c04412f626b21753aa9e1a1_r.jpg"> 
这时候,上司再说要改动轮子的设计,我们就只需要改动轮子的设计,而不需要动底盘,车身,汽车的设计了。

这就是依赖倒置原则——把原本的高层建筑依赖底层建筑“倒置”过来,变成底层建筑依赖高层建筑。高层建筑决定需要什么,底层去实现这样的需求,但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况。

控制反转(Inversion of Control) 就是依赖倒置原则的一种代码设计的思路。具体采用的方法就是所谓的依赖注入(Dependency Injection)。其实这些概念初次接触都会感到云里雾里的。说穿了,这几种概念的关系大概如下:

<img src="https://pic1.zhimg.com/50/v2-ee924f8693cff51785ad6637ac5b21c1_hd.jpg" data-caption="" data-rawwidth="1398" data-rawheight="630" class="origin_image zh-lightbox-thumb" width="1398" data-original="https://pic1.zhimg.com/v2-ee924f8693cff51785ad6637ac5b21c1_r.jpg"> 
为了理解这几个概念,我们还是用上面汽车的例子。只不过这次换成代码。我们先定义四个Class,车,车身,底盘,轮胎。然后初始化这辆车,最后跑这辆车。代码结构如下:

<img src="https://pic3.zhimg.com/50/v2-8ec294de7d0f9013788e3fb5c76069ef_hd.jpg" data-caption="" data-rawwidth="512" data-rawheight="717" class="origin_image zh-lightbox-thumb" width="512" data-original="https://pic3.zhimg.com/v2-8ec294de7d0f9013788e3fb5c76069ef_r.jpg"> 
这样,就相当于上面第一个例子,上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎(Tire)类,把它的尺寸变成动态的,而不是一直都是30。我们需要这样改:

<img src="https://pic4.zhimg.com/50/v2-64e8b19eeb70d9cf87c27fe4c5c0fc81_hd.jpg" data-caption="" data-rawwidth="534" data-rawheight="154" class="origin_image zh-lightbox-thumb" width="534" data-original="https://pic4.zhimg.com/v2-64e8b19eeb70d9cf87c27fe4c5c0fc81_r.jpg"> 
由于我们修改了轮胎的定义,为了让整个程序正常运行,我们需要做以下改动:

<img src="https://pic1.zhimg.com/50/v2-82e0c12a1b26f7979ed9241e169affda_hd.jpg" data-caption="" data-rawwidth="1186" data-rawheight="1452" class="origin_image zh-lightbox-thumb" width="1186" data-original="https://pic1.zhimg.com/v2-82e0c12a1b26f7979ed9241e169affda_r.jpg"> 
由此我们可以看到,仅仅是为了修改轮胎的构造函数,这种设计却需要修改整个上层所有类的构造函数!在软件工程中,这样的设计几乎是不可维护的——在实际工程项目中,有的类可能会是几千个类的底层,如果每次修改这个类,我们都要修改所有以它作为依赖的类,那软件的维护成本就太高了。

所以我们需要进行控制反转(IoC),及上层控制下层,而不是下层控制着上层。我们用依赖注入(Dependency Injection)这种方式来实现控制反转。所谓依赖注入,就是把底层类作为参数传入上层类,实现上层类对下层类的“控制”。这里我们用构造方法传递的依赖注入方式重新写车类的定义:

<img src="https://pic1.zhimg.com/50/v2-c920a0540ce0651003a5326f6ef9891d_hd.jpg" data-caption="" data-rawwidth="1338" data-rawheight="1424" class="origin_image zh-lightbox-thumb" width="1338" data-original="https://pic1.zhimg.com/v2-c920a0540ce0651003a5326f6ef9891d_r.jpg"> 
这里我们再把轮胎尺寸变成动态的,同样为了让整个系统顺利运行,我们需要做如下修改:

<img src="https://pic4.zhimg.com/50/v2-99ad2cd809fcb86dd791ff7f65fb1779_hd.jpg" data-caption="" data-rawwidth="1344" data-rawheight="1424" class="origin_image zh-lightbox-thumb" width="1344" data-original="https://pic4.zhimg.com/v2-99ad2cd809fcb86dd791ff7f65fb1779_r.jpg"> 
看到没?这里我只需要修改轮胎类就行了,不用修改其他任何上层类。这显然是更容易维护的代码。不仅如此,在实际的工程中,这种设计模式还有利于不同组的协同合作和单元测试:比如开发这四个类的分别是四个不同的组,那么只要定义好了接口,四个不同的组可以同时进行开发而不相互受限制;而对于单元测试,如果我们要写Car类的单元测试,就只需要Mock一下Framework类传入Car就行了,而不用把Framework, Bottom, Tire全部new一遍再来构造Car。

这里我们是采用的构造函数传入的方式进行的依赖注入。其实还有另外两种方法:Setter传递和接口传递。这里就不多讲了,核心思路都是一样的,都是为了实现控制反转。

<img src="https://pic1.zhimg.com/50/v2-861683acac47577c81f2b7493dd05649_hd.jpg" data-caption="" data-rawwidth="924" data-rawheight="298" class="origin_image zh-lightbox-thumb" width="924" data-original="https://pic1.zhimg.com/v2-861683acac47577c81f2b7493dd05649_r.jpg"> 
看到这里你应该能理解什么控制反转和依赖注入了。那什么是控制反转容器(IoC Container)呢?其实上面的例子中,对车类进行初始化的那段代码发生的地方,就是控制反转容器。

<img src="https://pic4.zhimg.com/50/v2-c845802f9187953ed576e0555f76da42_hd.jpg" data-caption="" data-rawwidth="1422" data-rawheight="628" class="origin_image zh-lightbox-thumb" width="1422" data-original="https://pic4.zhimg.com/v2-c845802f9187953ed576e0555f76da42_r.jpg"> 
显然你也应该观察到了,因为采用了依赖注入,在初始化的过程中就不可避免的会写大量的new。这里IoC容器就解决了这个问题。这个容器可以自动对你的代码进行初始化,你只需要维护一个Configuration(可以是xml可以是一段代码),而不用每次初始化一辆车都要亲手去写那一大段初始化的代码。这是引入IoC Container的第一个好处。

IoC Container的第二个好处是:我们在创建实例的时候不需要了解其中的细节。在上面的例子中,我们自己手动创建一个车instance时候,是从底层往上层new的:

<img src="https://pic2.zhimg.com/50/v2-555b2be7d76e78511a6d6fed3304927f_hd.jpg" data-caption="" data-rawwidth="2430" data-rawheight="168" class="origin_image zh-lightbox-thumb" width="2430" data-original="https://pic2.zhimg.com/v2-555b2be7d76e78511a6d6fed3304927f_r.jpg"> 
这个过程中,我们需要了解整个Car/Framework/Bottom/Tire类构造函数是怎么定义的,才能一步一步new/注入。

而IoC Container在进行这个工作的时候是反过来的,它先从最上层开始往下找依赖关系,到达最底层之后再往上一步一步new(有点像深度优先遍历):

<img src="https://pic3.zhimg.com/50/v2-24a96669241e81439c636e83976ba152_hd.jpg" data-caption="" data-rawwidth="2522" data-rawheight="354" class="origin_image zh-lightbox-thumb" width="2522" data-original="https://pic3.zhimg.com/v2-24a96669241e81439c636e83976ba152_r.jpg"> 
这里IoC Container可以直接隐藏具体的创建实例的细节,在我们来看它就像一个工厂:

<img src="https://pic2.zhimg.com/50/v2-5ca61395f37cef73c7bbe7808f9ea219_hd.jpg" data-caption="" data-rawwidth="2448" data-rawheight="524" class="origin_image zh-lightbox-thumb" width="2448" data-original="https://pic2.zhimg.com/v2-5ca61395f37cef73c7bbe7808f9ea219_r.jpg"> 
我们就像是工厂的客户。我们只需要向工厂请求一个Car实例,然后它就给我们按照Config创建了一个Car实例。我们完全不用管这个Car实例是怎么一步一步被创建出来。

实际项目中,有的Service Class可能是十年前写的,有几百个类作为它的底层。假设我们新写的一个API需要实例化这个Service,我们总不可能回头去搞清楚这几百个类的构造函数吧?IoC Container的这个特性就很完美的解决了这类问题——因为这个架构要求你在写class的时候需要写相应的Config文件,所以你要初始化很久以前的Service类的时候,前人都已经写好了Config文件,你直接在需要用的地方注入这个Service就可以了。这大大增加了项目的可维护性且降低了开发难度。
————————————————

Spring是一个开源框架相关推荐

  1. 再见Spring!下一个开源框架更香!

    在MyBatis 3.5.1这个版中有968个类.2770个字段.8422个方法.42504行代码.186428个指令码.其源码体量只有Spring 的1/5,也是Hibernate的1/5. 但在功 ...

  2. spring (由Rod Johnson创建的一个开源框架)

    你可能正在想"Spring不过是另外一个的framework".当已经有许多开放源代码(和专有)J2EEframework时,我们为什么还需要Spring Framework? S ...

  3. Spring:一个Java框架15年的演化

    作者:刘欣 来自:码农翻身(ID:coderising) 这篇文章来自于Spring创始人之一Juergen Hoeller在2018年的一次演讲(点击阅读原文查看),我觉得很有意思,又加了点儿料呈现 ...

  4. 如何快速学习一个开源框架

    你有个任务,需要用到某个开源项目;或者老大交代你一个事情,让你去了解某个东西.怎么下手呢?如何 开始呢?我的习惯是这样: 1.首先,查找和阅读该项目的博客和资料,通过google你能找到某个项目大体介 ...

  5. 从GitHub中整理出来的15个最受欢迎的Python开源框架,你喜欢哪个

    从GitHub中整理出的15个最受欢迎的Python开源框架.这些框架包括事件I/O,OLAP,Web开发,高性能网络通信,测试,爬虫等. Django: Python Web应用开发框架 Djang ...

  6. 【杂谈】超过12个,150页深度学习开源框架指导手册与GitHub项目,初学CV你值得拥有...

    之前我们公众号输出了很多深度学习开源框架相关的内容,今天整理成技术手册给大家分享以方便阅读,下面是详细信息. 开源框架背景 现如今开源生态非常完善,深度学习相关的开源框架众多,光是为人熟知的就有caf ...

  7. 【杂谈】面向新手的深度学习开源框架指导手册与GitHub项目,欢迎加入我们的开源团队...

    之前我们公众号输出了很多深度学习开源框架相关的内容,现在整理成技术手册给大家分享以方便阅读,下面是详细信息. 开源框架背景 现如今开源生态非常完善,深度学习相关的开源框架众多,光是为人熟知的就有caf ...

  8. 【通知】有三AI发布150页深度学习开源框架指导手册与GitHub项目,欢迎加入我们的开源团队...

    之前我们公众号输出了很多深度学习开源框架相关的内容,今天整理成技术手册给大家分享以方便阅读,下面是详细信息. 开源框架背景 现如今开源生态非常完善,深度学习相关的开源框架众多,光是为人熟知的就有caf ...

  9. 【完结】12大深度学习开源框架(caffe,tf,pytorch,mxnet等)快速入门项目

    这是一篇总结文,给大家来捋清楚12大深度学习开源框架的快速入门,这是有三AI的GitHub项目,欢迎大家star/fork. https://github.com/longpeng2008/yousa ...

最新文章

  1. 漫谈计算机体系.md
  2. 从无到有,支付路由系统升级打怪之路|原创
  3. 如何求欧拉函数~转载
  4. 如何在Eclipse里方便地进行markdown文件编辑
  5. swing下拉框从mysql_Java Swing应用程序 JComboBox下拉框联动查询
  6. java 跳转action_JS 跳转到指定Action | 学步园
  7. 基于Openstack的企业级实例在360的落地实战
  8. 解释抽象类继承实体类的前提是这个实体类必须明确构造函数
  9. bzoj 1151: [CTSC2007]动物园zoo
  10. 极光推送java服务器端_极光推送服务器端(JAVA)
  11. Flex 基于数据源的Menu Tree
  12. 数字化方法基础(二)_点的投影
  13. dapperpoco mysql_DapperPoco -- 基于Dapper的、轻量级的、高性能的、简单的、灵活的ORM框架...
  14. IPv4中IP地址分类
  15. Oracle 11G GoldenGate实现Windows与Windows之间的单向同步
  16. 【webservice】Axis2 客户端调用 设置超时时间
  17. android开发深入浅出,Android开发深入浅出RxJava(一:基础篇)
  18. XP高仿win7宽栏风格主题
  19. 【异常】The field file exceeds its maximum permitted size of 1048576 bytes.
  20. (黑客游戏)HackTheGame1.21 过关攻略

热门文章

  1. 育碧是如何做AI的? 《全境封锁》敌人AI设计思路分析
  2. Android自定义控件进阶03-Canvas之画布操作
  3. 深入剖析今年八大热门IT认证
  4. 15春到夏的逐渐绽开
  5. SOBS(背景建模)
  6. 华为MatePad Pro来临!首款鸿蒙平板性能全面升级!
  7. 10.1出游计划(成都市内)
  8. Gitolite轻松部署/管理git server
  9. kafka报错“Dependency ‘org.apache.kafka:kafka-clients:3.0.0‘ not found”
  10. 再次解读2006━2020年国家信息化发展战略