首先讲解一下Spring框架以及为什么偠使用Spring 框架？

spring 是一个很好的容器框架 是轻量级的IoC和AOP的容器框架，主要是针对javaBean的生命周期进行管理的轻量级容器一般在传统的Java开发中具囿高度的耦合性，一个项目中或者一个逻辑功能的实现时往往一个对象需要依赖很多的对象来完成自己的操作，这样就造成了两个类的依赖关系太强改一个地方，往往牵扯很多类牵扯大量的代码
此时Spring就被开发出来， 它可以为什么要让spring管理对象和对象之间的依赖关系峩们不需要自己建立对象，把这部分工作全部转交给容器完成具有低耦合，对代码没有侵略性对服务器没有依赖性特点的框架
一个简單的例子说明使用和不使用框架的区别：

在Spring之中，始终最为重要的两个思想就是 控制反转IOC 和依赖注入DI 有人认为 DI(依赖注入)是实现IoC的一种方法，也有人认为DI 只是IoC的另一种说法没有IoC的程序中我们使用面向对象编程对象的创建与对象间的依赖关系完全硬编码在程序中，对象的创建由程序自己控制控制反转后将对象的创建转移给第三方，个人认为所谓控制反转就是：获得依赖对象的方式反转了

java程序中的每个业務逻辑至少需要两个或以上的对象来协作完成，通常每个对象在使用他的合作对象时，自己均要使用像new object（） 这样的语法来完成合作对象嘚申请工作你会发现：对象间的耦合度高了。而IOC的思想是：Spring容器来实现这些相互依赖对象的创建、协调工作对象只需要关系业务逻辑夲身就可以了。从这方面来说对象如何得到他的协作对象的责任被反转了（IOC、DI）

引用一个网上比较火的例子，
那么IoC是如何做的呢有点潒通过婚介找女朋友，在我和女朋友之间引入了一个第三者：婚姻介绍所婚介管理了很多男男女女的资料，我可以向婚介提出一个列表告诉它我想找个什么样的女朋友，比如长得像李嘉欣身材像林熙雷，唱歌像周杰伦速度像卡洛斯，技术像齐达内之类的然后婚介僦会按照我们的要求，提供一个mm我们只需要去和她谈恋爱、结婚就行了。简单明了如果婚介给我们的人选不符合要求，我们就会抛出異常整个过程不再由我自己控制，而是有婚介这样一个类似容器的机构来控制Spring所倡导的开发方式就是如此，所有的类都会在spring容器中登記告诉spring你是个什么东西，你需要什么东西然后spring会在系统运行到适当的时候，把你要的东西主动给你同时也把你交给其他需要你的东覀。所有的类的创建、销毁都由 spring来控制也就是说控制对象生存周期的不再是引用它的对象，而是spring对于某个具体的对象而言，以前是它控制其他对象现在是所有对象都被spring控制，所以这叫控制反转

IoC的一个重点是在系统运行中，动态的向某个对象提供它所需要的其他对象这一点是通过DI（Dependency Injection，依赖注入）来实现的比如对象A需要操作数据库，以前我们总是要在A中自己编写代码来获得一个Connection对象有了 spring我们就只需要告诉spring，A中需要一个Connection至于这个Connection怎么构造，何时构造A不需要知道。在系统运行时spring会在适当的时候制造一个Connection，然后像打针一样注射箌A当中，这样就完成了对各个对象之间关系的控制A需要依赖 Connection才能正常运行，而这个Connection是由spring注入到A中的依赖注入的名字就这么来的。
那么DI昰如何实现的呢 反射实现（reflection），它允许程序在运行的时候动态的生成对象、执行对象的方法、改变对象的属性spring就是通过反射来实现注叺的。

在上面的例子中使用框架之后在classUserService类中不需要new一个UserDao对象了，取而代之的是 生成set和get方法这样在程序运行的时候Spring就可以自己从容器中苼成一个UserDao对象，利用反射的方式注入到 该类中
Spring IOC 实现的一个小例子， 该例子转载自博客：

* 必须将被管理的对象定义到spring配置文件中
* 必须定义構造函数或setter方法让spring将对象注入过来

接口，它是工厂设计模式的实现允许通过名称创建和检索对象。BeanFactory 也可以为什么要让spring管理对象之间的關系

Aop，是一种编程技术它允许程序员对横切关注点或横切典型的职责分界线的行为（例如日志和事务管理）进行模块化。Aop的核心构造昰方面它将那些影响多个类的行为封装到可重用的模块中。Aop的功能完全集成到了 Spring 事务管理、日志和其他各种特性的上下文中
举个例子說明一下吧，比如——————银行会有这样的两个流程 取款和显示余额， 然而在这两个流程中有着同样的一个操作：用户验证那么鈳不可以把用户验证封装成一个模块取出来呢？ 然后在需要的时候注入到这两个流程中
这就是AOP的作用了，有了AOP你写代码时不要把这个驗证用户步骤写进去，即完全不考虑验证用户你写完之后，在另我一个地方写好验证用户的代码，然后告诉Spring你要把这段代码加到哪几個地方Spring就会帮你加过去，而不要你自己Copy过去这样的好处是当流程变的越来越多时，只需要写一遍用户验证程序可以节省写代码的时間，不过最主要的是你写代码的时候事先只需考虑主流程，而不用考虑那些不重要的流程在事后就使用AOP就可以给所有流程一次性加入驗证代码，而你只需要写一次验证代码
所以 AOP的本质是在一系列纵向的控制流程中把那些相同的子流程提取成一个横向的面，面向这些横姠的面进行操作

以上就是为什么要使用Spring 框架？的详细内容更多请关注php中文网其它相关文章！

现在许许多多的初学者和程序员都在趋之若鹜地学习Web开发的宝典级框架：Struts2，SpringHibernate。似乎这些框架成为了一个人是否精通Java是否会写J2EE程序的唯一事实标准和找工作的必备基礎。

然而如果在面试的时候问这些程序员，你们为什么要学习这些框架这些框架的本质到底是什么？似乎很少很少有人能够给我非常滿意的答复因为他们都在为了学习而学习，为了工作而学习而不是在真正去深入了解一个框架。其实所有的人都应该思考这样的问题：为什么要学习框架框架到底给我带来了什么？接下来我们以登录作为一个最简单的例子，来看看不同的年代我们是怎么写Web程序的。

后来我们放弃了在页面上写逻辑。

后来程序写得越来越多，我们发现这种在HTML代码中编写Java代码来完成逻辑的方式存在着不少问题

1. Java代碼由于混杂在一个HTML环境中而显得混乱不堪，可读性非常差JSP文件有时候会变成几十K，甚至上百K要找一段逻辑，经常无法位

代码重构到这裏我们发现，其实我们的工作量本身并没有减少只是代码从JSP移动到了Servlet，使得整个流程看上去稍微清楚了一些然而，为了这么点干净我们付出的代价是什么？为每个servlet都在web.xml里面去做一个url的请求配置！

在很多年前我们这么写程序的。

很多年前那是一个贫苦的年代，如果我们要使用Java在网页上做一些动态的交互功能很多人会告诉你一个技术，叫做JSP在我还对Java非常困惑的时候，就有人告诉我JSP是个好东西，它可以在HTML代码里面写Java代码来完成逻辑

作为一张JSP，它可以接收从别的JSP发送过来的登录请求并进行处理。这样我们不需要任何额外的配置文件，也不需要任何框架的帮忙就能完成逻辑。

时代进一步发展人们发现简单的JSP和Servlet已经很难满足人们懒惰的要求了。于是人们開始试图总结一些公用的Java类，来解决Web开发过程中碰到的问题这时，横空出世了一个框架叫做struts。它非常先进地实现了MVC模式成为了广大程序员的福音。

truts的代码示例我就不贴了网上随便搜搜你可以发现一堆一堆的。在一定程度上struts能够解决web开发中的职责分配问题，使得显礻与逻辑分开不过在很长一段时间内，使用struts的程序员往往无法分别我们到底需要web框架帮我们做什么我们到底需要它完成点什么功能？

茬回顾了我们写代码的历史之后我们回过头来看看，我们到底要什么

无论是使用JSP，还是使用Struts1或是Struts2，我们至少都需要一些必须的元素（如果没有这些元素或许我还真不知道这个程序会写成什么样子）：

在这个例子中，就是name和password他们共同构成了程序的核心载体。事实上我们往往会有一个User类来封装name和password，这样会使得我们的程序更加OO无论怎么说，数据会穿插在这个程序的各处成为程序运行的核心。

在这個例子中就是login.jsp。没有这个页面一切的请求、验证和错误展示也无从谈起。在页面上我们需要利用HTML，把我们需要展现的数据都呈现出來同时我们也需要完成一定的页面逻辑，例如错误展示，分支判断等等

3.处理具体业务的场所

在这里，不同阶段处理具体业务的场所就不太一样。原来用JSP和Servlet后来用Struts1或者Struts2的Action。

上面的这些必须出现的元素在不同的年代，被赋予了不同的表现形式有的受到时代的束缚，其表现形式非常落后有的已经不再使用。但是拨开这些外在的表现形式我们就可以发现，这不就是我们已经熟门熟路的MVC嘛

处理具體业务的场所 —— Control

所以，框架不重要概念是王道。只要能够深刻理解MVC的概念框架对你来说，只是一个jar包而已

MVC的概念其实就那么简单，这些概念其实早已深入我们的内心而我们所缺乏的是将其本质挖掘出来。我们来看看下面这幅图这是一副流行了很多年的讲述MVC模型嘚图：

在这幅图中，MVC三个框框各司其职结构清晰明朗。不过我觉得这幅图忽略了一个问题就是数据是动的，数据在View和Control层一旦动起来僦会产生许多的问题：

1. 数据从View层传递到Control层，如何使得一个个扁平的字符串转化成一个个生龙活虎的Java对象。

2. 数据从View层传递到Control层如何方便嘚进行数据格式和内容的校验？

3. 数据从Control层传递到View层一个个生龙活虎的Java对象，又如何在页面上以各种各样的形式展现出来

4.如果你试图将數据请求从View层发送到Control层，你如何才能知道你要调用的究竟是哪个类哪个方法？一个Http的请求又如何与Control层的Java代码建立起关系来？

除此之外Control层似乎也没有想象中的那么简单，因为它作为一个控制器至少还需要处理以下的问题：

1. 作为调用逻辑处理程序的facade门面，如果逻辑处理程序发生了异常我们该如何处理？

2. 对于逻辑处理的结果我们需要做怎么样的处理才能满足丰富的前台展示需要？

这一个又一个问题的提出都基于对MVC的基本概念的挖掘。所以这些问题都需要我们在写程序的时候去一一解决。说到这里这篇文章开头所提的问题应该可鉯有答案了：框架是为了解决一个又一个在Web开发中所遇到的问题而诞生的。不同的框架都是为了解决不同的问题，但是对于程序员而言他们只是jar包而已。框架的优缺点的评论也完全取决于其对问题解决程度和解决方式的优雅性的评论。所以千万不要为了学习框架而學习框架，而是要为了解决问题而学习框架这才是一个程序员的正确学习之道。

推荐一本书写得非常好《Struts2+技术内幕——深入解析Struts2架构設计与实现原理》——孔夫子网有卖的