本篇内容介绍了“Spring Context基础知识点有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
员工经过长期磨合与沉淀，具备了协作精神，得以通过团队的力量开发出优质的产品。创新互联坚持“专注、创新、易用”的产品理念，因为“专注所以专业、创新互联网站所以易用所以简单”。公司专注于为企业提供成都做网站、成都网站设计、微信公众号开发、电商网站开发，微信小程序定制开发，软件定制网站等一站式互联网企业服务。
作为从事java开发的码农，Spring的重要性不言而喻，你可能每天都在和Spring框架打交道。Spring恰如其名的，给java应用程序的开发带了春天般的舒爽感觉。Spring，可以说是任何一个java开发者通往技术高阶的必备基础。当然，要学好Spring，尤其是了解Spring的底层原理并不容易，需要花费很多时间和精力来潜心的研习，并在实际的项目中不断的试错和总结，才能形成属于自己的思维理解。博主对Spring最初的认识颇浅，项目中遇到问题依靠度娘大概也能笼而统之的解决。不过呢，接触Spring这么一年多时间里，对其框架体系认知比较杂乱，深层技术依然是雾里看花一般，没有形成自己的认知和理解，这对编程技术的提升是十分不利的。鉴于此，才决定静下心来从头至尾系统的学习Spring框架，并通过博客的形式记录学习点滴，分享技术知识，算是抛砖引玉吧。好了，闲言少叙，咱们开始切入正题
DI(Dependency Injection)，依赖注入。和我们常听说的另一个概念 IOC(控制反转)其实归根结底实现的功能是相同的，只是同样的功能站在不同的角度来阐述罢了。这里博主就不去过多的辨析，度娘上有一大堆解释。我们需要知道的是，什么叫依赖注入，为什么要依赖注入。搞清这两点，我想对Spring的学习在思想上就算是上道了。
在没用使用Spring的时候——也就是没有依赖注入的时候，java应用程序的类与类之间要实现相互的功能协作是比较费劲的，某个类(A)要实现它的功能如果需要依赖另一个类(B)的协作的话，就需要在A类中主动创建出B类的对象，才能使用B类的方法完成功能(这里看官就不要去纠结静态方法之类的情况了)。这等于是A类需要负责B类对象整个生命周期的管理。在极度简单的情况下，在一个类中new出另一个类的对象似乎并没有什么问题，但是复杂的应用程序类与类的协作关系往往是多边的，我们并不知道一个类功能的实现会依赖多少个另类对象来协作，所以在类中自行创建对象并且管理对象的整个生命周期，会造成代码的高度耦合以及不可想象的复杂度。那么，试想，如果我们能将对象的生命周期交给第三方组件来管理，当某个类需要另外的对象时第三方组件就直接创建出来交给它，这样，类就可以只专注于自己功能的实现，而不用去管理其他类对象的生命周期，这样类的功能就单纯了很多。
是的，你一定已经明白了，Spring(容器)就是这个第三方组件。我们只需要告诉Spring(容器)有哪些对象需要管理就行了，不用去关心Spring框架是如何创建对象的。这样，当某个类A需要类B对象时，如果类B已经声明交给了Sping容器管理，那么在程序运行到类A需要类B时，Spring容器就通过依赖注入的方式，将类B对象注入到类A中协助完成业务功能。通过第三方组件的依赖注入，对象无需再自行的创建和管理类与类之间的依赖关系了。对象的创建依赖注入的方式也有多种，譬如接口注入，构造方法注入，setter方法注入等等。说到这里，你对依赖注入应该有比较直白的认知了。至于为什么要依赖注入，上文已经说得很明白了，就是为了减少代码中组件之间的耦合度，我们还是先通过简单示例来直观感受下依赖注入比自己管理对象的好处吧
public class Man implements Human {
private QQCar car;
public Man() {
this.car = new QQCar();
}
@Override
public void xiabibi() {
}
public void driveCar(){
car.drive();
}
}接口Car暂有两个实现：奔驰车和QQ车，在以上Man类和QQCar类高度耦合的代码中，老司机通过构造器只创建了QQ车对象，所以只能开QQ车，那么老司机想开奔驰怎么办呢，你让他重新创建奔驰车的对象吗？这样高度耦合的代码似乎是毫无办法的，那么，我们通过注入对象的方式对上述代码做一番改进：
public class Man implements Human {
private Car car; //注意此处哦
public Man(Car car) {
this.car = car;
}
@Override
public void xiabibi() {
}
public void driveCar() {
car.drive();
}
}以上代码根据多态特性，通过构造器接口注入的方式屏蔽掉了具体的对象实现，这样，老司机就能想开什么车就开什么车了。这就是依赖注入带来的好处。
AOP(Aspect Oriented Programming)，面向切面编程。日常开发中，我们在完成某个业务功能的时候，写了一堆代码，到最后代码优化的时候发现，真正完成业务的代码可能就那么两句，而其余都是与该部分业务相关度不大，仅仅是为了实现某种技术的代码，是完全可以抽离出去的，于是很自然的，我们会将其抽取成一个工具类，这样凡是用到的地方只需调用一下工具方法就ok了。我们再站高一点看，各个业务模块的功能组件中除了完成相关的业务功能外，都有涉及日志、事务、安全控制等额外的操作等。这些并不是模块的核心功能，却又不可或缺。如果将这些额外功能添加进代码，业务系统每个组件都来一套又显得太过重复，而且让业务代码显得混乱，不够纯粹。
这个时候，你问上帝，可不可以让你的业务代码只专注于业务的实现，不去管什么日志、事务等不相干的东西？喔，上帝说没问题，于是就有了AOP。如果说依赖注入的目的是让相互协作的组件保持一种较为松散的耦合状态的话，AOP则是将遍布应用各处的功能分离出来形成可重用的组件。通俗点说，日志、事务等都是可以重用的组件，我们完全可以将分散于业务代码各处的日志、事务、安全等功能代码抽离出成为一个单独的工具组件，在Spring的配置中将其进行声明为一个功能切面，再告诉Spring你想在哪些地方、什么时机使用（切入）这些可重用组件就行了。这就是对面向切面的简单释义。
有了Spring之后，通过依赖注入的方式，我们的业务代码不用自己管理关联对象的生命周期。业务代码只需要按照业务本身的流程，走啊走啊，走到哪里，需要另外的对象来协助了，就给Spring说，我想要个对象 于是Spring就很贴心的给你个对象。听起来似乎很简单，使用起来也不难，但是如果仅仅是这样的拿来主义，倒也洒脱，不用费什么脑子。。。可是，你就真的不关心，Spring是从哪里把对象给你的吗？
如果你想要了解Spring深一些，而不仅仅是拿来用用，那么你就应该好好思考一下上诉问题，不然，你还看个铲铲啊！你可以这样去思考：Spring既然要负责应用程序中那么多对象的创建管理，就像苹果要生产那么多的手机（对象）一样，肯定有一个专门搞对象的地方。苹果生产手机的地方叫工厂，比如富士康，但放在软件开发中，对于Spring搞对象的地方我们就不叫工厂了，而叫做容器。是的，容器的概念在java中你最熟悉的莫过于Tomcat了，它正是一个运行Servlet的web容器，而Spring要想实现依赖注入功能，就离不开对象生产的容器——如果没有容器负责对象的创建管理，你的程序代码只是喊要对象了，Spring也无处给你啊。实际上，容器是Spring框架实现功能的核心，容器不只是帮我们创建了对象那么简单，它负责了对象整个的生命周期的管理——创建、装配、销毁。关于Spring的这个容器你最常听闻的一个术语就是IOC容器。所谓IOC，是一种叫控制反转的编程思想，网上有很通俗易懂的总结，我就不胡乱阐述了。
总之一句话，我的应用程序里不用再过问对象的创建和管理对象之间的依赖关系了，都让IOC容器给代劳吧，也就是说，我把对象创建、管理的控制权都交给Spring容器，这是一种控制权的反转，所以Spring容器才能称为IOC容器。不过这里要清楚一点：并不是说只有Spring的容器才叫IOC容器，基于IOC容器的框架还有很多，并不是Spring特有的。
好了，终于把Spring的容器概念阐述的差不多了，但有什么卵用呢？光有容器你其实什么都干不了！你以为容器那么科幻，跟叮当猫面前的百宝袋一样，你想要啥它就给你啥？实际上，容器里面什么都没有，决定容器里面放什么对象的是我们自己，决定对象之间的依赖关系的，也是我们自己，容器只是给我们提供一个管理对象的空间而已。那么，我们怎么向容器中放入我们需要容器代为管理的对象呢？这就涉及到Spring的应用上下文了。
什么是应用上下文呢，你可以简单的理解成就是将你需要Spring帮你管理的对象放入容器的那么一种。。一种。。额。。一种容器对象——是的，应用上下文即是Spring容器的一种抽象化表述；而我们常见的 ApplicationContext 本质上说就是一个维护Bean定义以及对象之间协作关系的高级接口。
应用上下文Context：基于 Core 和 Beans，提供了大量的扩展，包括国际化操作（基于 JDK ）、资源加载（基于 JDK properties）、数据校验（Spring 自己封装的数据校验机制）、数据绑定（Spring 特有，HTTP 请求中的参数直接映射称 POJO）、类型转换，ApplicationContext 接口是 Context 的核心，可以理解为Bean的上下文或背景信息。
PS：官方文档里面对 *Context 相关的类的描述本来就是通过读取xml文件中的信息，再通过动态代理生成具体对象，这里的context狭义上就是指描述类信息的xml文件，实际这里翻译为 描述或者周围环境配置 更准确。
这里，我们必须明确，Spring的核心是容器，而容器并不唯一，框架本身就提供了很多个容器的实现，大概分为两种类型：一种是不常用的BeanFactory，这是最简单的容器，只能提供基本的DI功能；还有一种就是继承了BeanFactory后派生而来的应用上下文，其抽象接口也就是我们上面提到的的ApplicationContext，它能提供更多企业级的服务，例如解析配置文本信息等等，这也是应用上下文实例对象最常见的应用场景。有了上下文对象，我们就能向容器注册需要Spring管理的对象了。对于上下文抽象接口，Spring也为我们提供了多种类型的容器实现，供我们在不同的应用场景选择
AnnotationConfigApplicationContext：从一个或多个基于java的配置类中加载上下文定义，适用于java注解的方式；
ClassPathXmlApplicationContext：从类路径下的一个或多个xml配置文件中加载上下文定义，适用于xml配置的方式；
FileSystemXmlApplicationContext：从文件系统下的一个或多个xml配置文件中加载上下文定义，也就是说系统盘符中加载xml配置文件；
AnnotationConfigWebApplicationContext：专门为web应用准备的，适用于注解方式；
XmlWebApplicationContext：从web应用下的一个或多个xml配置文件加载上下文定义，适用于xml配置方式
有了以上理解，问题就很好办了。你只要将你需要IOC容器替你管理的对象基于xml也罢，java注解也好，总之你要将需要管理的对象（Spring中我们都称之问bean）、bean之间的协作关系配置好，然后利用应用上下文对象加载进我们的Spring容器，容器就能为你的程序提供你想要的对象管理服务了。下面，还是贴一下简单的应用上下文的应用实例：
我们先采用xml配置的方式配置bean和建立bean之间的协作关系：
