对于一个Java Web服务端开发人员来说,Spring这样一个应用开发框架可谓是工作中密不可分的好搭档。但夫妻尚能不和,兄弟也会反目,和Spring这位老搭档呆久了,我躁动的内心不时也会冒出一些“疯狂”的想法:如果有一天Spring消失了,我该用什么来完成开发工作?
哈哈哈,不得不说上面这个想法还是有点疯狂的。但细细思索,Spring作为我们的搭档是否做得过于贴切了,以至于离开了Spring会让我们感到无所适从、难以为继。每每思索至此,我不禁暗自感叹:难道我是一个Spring工程师而不是一个Java工程师?令人悲哀的是,我的工作确实很大一部分就是在面向Spring以及Spring生态相关的工具进行编程。
但如果某一天我们真的想要离开Spring的怀抱,我们就需要弄清楚Spring到底为我们做了什么?
首先,让我们回到最初的原点,回到与Java初见的那一天。在见面的第一天,Java就告诉我们在它的世界中万事万物皆为对象,一切行为方法都需要类去定义,需要通过对象去执行。也就是说,从我们接触Java的第一天开始我们就开始面向对象(或者说是POJO类)进行编程。但仅仅如此是没有办法满足企业开发需求的(企业级开发更多关注的是如何操作企业资源来完成相应的业务逻辑,比如如何操作数据库资源、如何进行事务处理、如何进行远程调用等等),所以为了满足企业开发的需要,Sun公司推出了企业级应用开发平台J2EE。当然这里将其称为开发平台并不非常合适,J2EE自诞生依赖更多的是作为一种企业开发规范在进行使用和推广。伴随着J2EE的出现,一款企业级开发框架EJB也随之诞生。不过看到今日Spring一家独大的场景,想必大家都已经了解了EJB的下场。但是作为亲儿子的EJB因何沦落到如此地步呢?这里博主简单搜索了一下网上评价,评价内容大同小异,就是太难用了,完全不符合开发的习惯。EJB沉重的设计理念完全是为了一丝不苟地符合J2EE规范,而不是给开发人员提供一个快捷方便易上手的开发框架,这种反开发的操作让EJB在Spring推出之后瞬间被抛诸脑后。
Spring自诞生开始就着眼于降低开发人员企业开发的难度、提升开发的效率,其最重要的设计思路就是让开发人员能够很简单的面向POJO类编程,无须像使用EJB一样需要先了解框架内所提供的对象概念,然后按照指定方式进行指定对象的使用。除此以外,针对企业资源操作的J2EE服务组件,Spring进行内部的封装以及通过面向接口编程的方式实现了功能组件的可插拔式引入,这样既提供了开发人员功能组件选择的自由度,也屏蔽了一些功能组件的实现细节,降低开发人员的使用成本。
从上图中我们可以看出,Spring作为一个轻量级的应用开发框架提供了以IoC容器和AOP模块为核心的JavaBean管理能力以及应用开发所需的功能组件(封装好的J2EE服务组件)。这里需要特别注意,Spring中提供的所有能力都是依赖于IoC容器和AOP模块这两个核心完成,这两个核心能力也是Spring框架设计理念最重要的体现。
IoC容器和AOP模块作为Spring的C位成员,相信诸位一定不会陌生。对于这两个模块的概念网络上已经有太多的博客和文章进行了讲解,这里就不再具体介绍了,只是简单说明一下:
IoC容器
:IoC容器提供Spring框架最重要的JavaBean管理能力,通过容器以及围绕容器提供的支持(比如Resource访问资源的抽象、国际化以及事件驱动等)极大地方便了开发人员的编码工作;AOP模块
:基于JVM动态代理/CGlib实现的对于对象增强的功能模块,让开发人员在实际开发中能够较为轻松地进行非业务逻辑的通用处理;上面我们也谈到了对于企业开发来说,通过操作企业资源(数据库、内部服务)来完成相应的业务逻辑开发是其最核心的任务。基于这一需求,Spring提供了如下功能组件来完成支持工作:
Spring JDBC/ORM
:Spring基于JDBC规范的基础上进一步进行了数据库相关操作的封装处理,提供了更为简洁的API操作方式和对象映射能力。除此以外,Spring还提供了对于主流ORM工具的集成和封装,使得开发者不仅可以自由选择对应的ORM,同时还可以将Spring的事务管理能力和ORM工具的使用结合起来;Spring远程调用
:Spring内部封装了一整套应用间通信和调用的实现逻辑,来实现应用间的远程调用。当然在微服务盛行的今天,大家使用的更多的可能是诸如SpringCloud、Dubbo、gRPC等服务治理框架来进行远程调用;Spring MVC
:从学习Spring的第一天开始就是使用Spring的MVC框架进行Web开发。时至今日,可以说绝大部分互联网公司的都会并且愿意使用Web应用作为软件发布方式,毕竟Web应用只要有浏览器就可以在多端设备上打开。并且即使是移动端设备,如果想接入到互联网中也需要有对应Web服务端来支持;粗略地捋了一下Spring的功能以及现行工具的支持,不得不感叹如果离开了Spring还真是有点寸步难行。无论是选择自己另起炉灶还是使用市面已有的替代产品,中间件支持、数据库操作等等J2EE相关的功能组件都需要重新考虑集成问题,且学习上也会有很大的困难。
所以,如果Spring消失了,我们大概会回到农耕时代刀耕火种,然后等待着下一个Spring的诞生,哈哈哈~~
本文分享自 Brucebat的伪技术鱼塘 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!