捋一捋那些年让我们傻傻分不清楚的spring系框架

最新推荐文章于 2024-04-17 11:35:35 发布

Automannnn

最新推荐文章于 2024-04-17 11:35:35 发布

阅读量323

点赞数

分类专栏：框架相关

本文链接：https://blog.csdn.net/qq_36285943/article/details/79937001

版权

框架相关专栏收录该内容

36 篇文章 1 订阅

订阅专栏

本来打算今天一开始就为将可能参加的一个比赛做准备的，包括从后台到前台。虽然框架啥的用起来没有问题了，可是总感觉自己没有一个总体上的认识，索性就再补一补相关的知识，至少有一个宏观的把控了，再着手做吧。

反正我是听说了各种spring的相关产品，网上各种教程也很全。但是总有一种华而不实的感觉，真正要深刻的体会到还是得自己亲身实践。于是，按照网上大牛的一些思路，再结合自己的实际情况，索性就直接去maven respository里面去看看吧。来一个总体的认识。

在maven仓库中，输入 spring,可以发现与这个关键词相关的产品有8000种之多

如图：

但是这里我主要想看的是apache的那些个官方的东西，按照相关性排序，可以看到：

后面还有好些个，但是是分散的，可以看到，它们的机构名为： org.springframework,后面的文件名称即为它的项目名。那么如果我们说spring框架是指什么呢？还是说没有这种说法呢？我也不清楚，毕竟听得太多了，傻傻分不清楚。希望通过这次的学习能够了解一些，将它们分辨开来。

但从这里来说，也就是说它们是一个平行的产品，每一个都应该是可以拿出来单用的，并不一定要配合到一起才能用，我想这是第一点自己打算猜测的吧。

第二个我想理解的是：机构名： org.springframework 与 org.springframework.boot,它们的关系应该怎么理解呢？从一个名字来说，尽管它们前缀是一样的，但是我们却必须把它们当成两个完全不同的事物，虽然它们有可能出自同一机构。但是从我们的编程习惯而言，org.springframework中的 “.”可以被我们理解成路径，这样的话，boot就会被理解为springframework目录的下一集目录，从逻辑上便有可能有一个先入为主的想法：它们是继承关系，或者说包含关系等。从这二者的思想，我宁愿选择第一种，将它们当成两个素不相识的路人，然后互相合作而已（或者说单方面合作更恰当吧）。

接着还是继续将机构： org.springframework下的产品给列出来吧：这里直接点到 springframework下面去，发现这里是一条条的比上面的有逻辑，那就一个一个的在截图一遍，以期能够记住它们吧（反正我想csdn也不差这点空间）：

context,英文意思为”上下文，环境，语境“的意思，这个好像是跟 xml 文件有点关系的，毕竟有一个环境的意思嘛，而且xml也很多用于作配置文件。同时作为一个环境有关的类的话，自然在程序启动时加载了，所以某一个spring产品的启动类好像就位于此处。如名称为ApplicationContext的，又比如名称为ClassPathXmlApplicationContext的等等。

其名字为 spring-core,自然是很重要，毕竟core是核心的意思嘛。并且根据经验加直觉，其他的产品有可能要依赖它运行。通过查询资料，可以发现大牛十分中肯的见解：

Spring core是核心层，拥有这BeanFactory这个强大的工厂，是所有bean的管理器；
而spring context是上下文运行环境，基于spring core之上的一个架构

Spring core是用来负责发现、创建并处理bean之间的关系的一个工具包；可以这么理解，core把bean的创建、bean的互相注入的方法定义好了，上层服务只需要调用就好了；提供功能但不调用就是spring core的存在意义。

我们知道Bean包装的是Object，而Object必然有数据，如何给这些数据提供生存环境就是Context要解决的问题，对Context来说他就是要发现每个Bean之间的关系，为它们建立这种关系并且要维护好这种关系。所以Context就是一个Bean关系的集合，这个关系集合又叫Ioc容器，一旦建立起这个Ioc容器后Spring就可以为你工作了。

Context作为Spring的Ioc容器，基本上整合了Spring的大部分功能，或者说是大部分功能的基础，所以它调用了大部分的spring core中的方法。

可以从大牛的言论中了解到，context作为了Spring的Ioc容器，Ioc,全称为：Inversion of Control,但是每次我看到简称的时候都不能将中文与它对应起来，总想着怎么也该C打头吧。或者说 Control Inversion。但是人家不是按照中文的习惯，咱也没办法。那我以后干脆叫做控制的反转吧。哈哈哈。免得自己每次都搞混。究其根源，还是练的不够，作业太少！对于ioc，还有一个经常容易跟他搞混的是： DI(dependency insert) 依赖注入，这个就符合中文的习惯，我一下就能认出来哈哈哈。把他们从名字上区别开来后，其他的就好办了：直接一句话解决： ioc 包括了依赖注入和依赖查找。这里还想记录的一点，认为对自己理解很重要的就是这里的依赖是一个名词，而非动词！！中文种四个汉字表一个动词的例子也是有的：比如极目远眺。

见名知意： bean工厂。

见名知意系列。

见名知意系列。但是不知道它跟web 有啥具体的区别与联系，以后有机会研究。现在不正是个机会嘛，直接去看大牛的解释了：

如果我单独包含 spring-webmvc ，那么 spring-web 就会隐式添加进来。

我们什么时侯应该单独使用 spring-web 呢？

spring-web 提供了核心 HTTP 集成，包括一些便捷的 servlet 过滤器， Spring HTTP 调用，用于集成其它 web 框架的基础结构以及技术（Hessian，Burlap）。

spring-webmvc 是 Spring MVC 的一个实现。spriing-webmvc 依赖于 spring-web，这样包含它就会间接地添加 spring-web。不必显示添加 spring-web。

如果你不使用 Spring MVC ，但想要借助其它 Spring 支持的 web 相关技术的优势，那么你只需依赖 spring-web 。

区别一目了然。spring-webmvc包含了 spring-web。同时看一下百度回答的答案：又一定参考价值

<span style="color:#999999">        个人理解的一个简单区别：

            1、web主要是spring controlle层的一些核心封装。
            2、web-mvc主要是一些view层的核心封装，提供各前端技术及标签支持。</span>

继续看下一个产品：

见名知意系列。

AOP，全称为：Aspect Oriented Programming,面向切面编程。这是我感觉理解起来比较吃力的。同时它的源码也是相当之复杂的那种。练习过一点点，越学越蒙。网上去搜各种资料也是说的神乎其神，非常玄乎。现在回过头来看，抛弃所有的知识约束，所有的规范约束，谈谈自己的理解：我们知道树的遍历可以分为深度优先和广度优先，那么面向切面就相当于广度优先遍历吧。尽管在实现的逻辑上，还是深度优先的，但是注意这里指面向切面编程，核心词汇应该是编程，表明的是一种方式方法。再谈一谈它的表现方式吧：自己的理解不一定准确：比如我们开发网站后台时，通常会有：controller,service,dao。但是它们存在某种对应关系，如果正常情况下的话，我们应该是将某个方法完全的给实现了，然后丢给bean工厂让他给我们管理依赖关系。这样的就不易于有一个很好的总体观，对于项目的开发可能会由于某一个局部的问题而陷入困境，从而打断自己的整体思路。考虑这样的一种情况，我们不用aop，而是用ioc的话,当我们写完dao了之后，去写servie,将每个方法实现，然后再去写 controller,然后将它们的依赖关系给配置好。效果上也是一样的，没有毛病。因此，aop我觉得可以算作一种编程的方法，而不是某一种技术还好点。如果真的要从技术来考虑的话，那就是我们可以在依赖中写某一个接口，然后他会根据这个接口去找它的实现类。而 ioc则必须写实现类。。另外，它的实现是基于java的动态代理好像，而Ioc的则是基于java的反射机制。所以归根结底还是傍上java这个大树。我的理解是这样。并且我在AspectJ的包下面看到了有史以来最长的一个类名，现在回想起来，应该有30到50个ascll英文长度吧，把我吓坏了。

这个好像是给第三方准备的，用来支持第三方应用的ioc支持。

ORM,对象关系映射，用的比较多的，也是非常蒙蔽的。什么hibernate啊,mybaties啊,jpa啊，jdo啊，分不清楚。尽管已经看过好几遍资料关于它们的相关介绍，都是睡一觉之后就忘了。难以深刻理解的原因在于什么呢？我想是对其理解不够，如果有机会将它的源码看一看，或者调试一遍，我打包票这辈子是没有忘的机会了。尽管这样，还是看看大牛的中肯的解释吧：

可惜的是没有暂时没有找到我认为比较贴切的解释。不过在寻找途中我有如下一些感悟：

1.ORM框架是一个独立的技术门类或者说是某一领域的技术吧，并不是因为有了Spring然后才有了ORM，Spring对其进行了集成。

2.就是关于Spring集成方面的。试想一下，很久以前的某个时间段，Spring初出茅庐，江湖上并没有它的一席之地。那会，它也没有这么多耀眼的光环，有的只是：Spring-core,Spring-Context,Spring-beans这几个稀稀落落的核心成员。然后通过不断打拼，才有了诸如 Spring-JDBC,Spring-orm,Spring-tx。那么它们是怎么来的呢？就有点像现代企业竞争中的联合或者兼并，它这里主要的是联合。进入其他的技术领域，将它里面的技术关键点搞清楚，依赖关系搞清楚，结合自身强大的解耦的功能，联合之后迅速就在江湖一方称雄称霸。直到今天的耀眼光环。所以这里说到了集成，也就应该是除了核心的ioc,bean，aop,等核心部件，其他都应该是集成而来。它的竞争力在于它极强的解耦性。

3.还是集成方面。如果集成的话，集成某一个产品则推出的应该是一个产品。如： Spring-redis,Spring-mybatis，Spring-Hibernate。对应的java 类的话就应该基本类。而现在是这种情况，它集成的是某一个技术领域： Spring-ORM，这就尴尬了。它集成出来的是个啥玩意呢？我猜想应该就是一个模板的作用吧，对应于java 中的接口或者抽象类。核心在于他为我们的集成ORM这个技术领域进行了一些必要的准备和支持。如果我们要使用的话，则必须具体化，也就是指定具体的实现类。从这种意义上来说，可以将 Spring-orm 看作是 Spring-hibernate 或者 Spring-mybatis 等的父类，实现了Srping-hibernate,也就相当于使用了Spring-orm,类似于 Spring-mvc 与 Spring-webmvc的关系吧。

4.每个集成产品的关系应该会在它当前的jar包下的spring配置文件中说明，在我们项目搭建中有时需要去除某一个依赖，但是又怕去错了导致程序出错。就可以参考根据这个思路去处理。但是一般情况下这些都是大佬做的，内容也很复杂。但这并不能阻挡我们求知的决心嘿嘿嘿。