Spring注解配置和xml配置优缺点比较
Spring注解配置和xml配置优缺点比较
在昨天发布的文章《spring boot基于注解方式配置datasource》一文中凯哥简单的对xml配置和注解配置进行了比较。然后朋友看到文章后,就问:那你说说这两种区别。
额,说真的,还真把凯哥给问蒙圈了。本文来源:凯哥Java【kaigejava】
凯哥当时就回答:注解的方便。如果再深入呢?还真说不明白。
是啊,现在都在说注解好,但是注解和xml比较起来有哪些优点呢?xml又为什么不好呢?有没有深入思考过么?以下内容是凯哥从网上找的并加以理解的。
想要弄清楚这个,我们先来看看Xml.
就目前Java web 开发应用中都能见到用xml作为配置的身影。在常用的框架中如:struts、spring mvc、hibernate、mybites等这些框架中(早期版本表现更为突出)都有xml配置。
我们就来看看XML的优点:
Xml优点
1:xml是集中式的元数据,不需要和代码绑定的;
在我们开发中,xml配置文件和代码类是区分开的。不需要绑定到代码中
2:使用xml配置可以让软件更具有扩展性;
比如,我们在spring中,我们不想使用接口而是想用接口的实现类,这个时候只需要修改xml配置中bean的class值就可以了。
3:对象之间的关系一目了然;
比如,我们在基于xml配置读取配置信息,如下图:
从xml结构中,我们就可以看出,在popertyPlaceholderConfigure类里面有个locations的属性,而且是list集合。
再比如,使用xml配置数据源的是:
DataSource对象的属性一目了然。
4:xml定义:可扩展标记语言,标准通用标记语言的子集,简称XML。从这个定义中我们可以发现,xml最大的优势就在于,开发者(程序员)能够为软件量身定做使用的标记,使得xml更通俗易懂;
5:成熟的校验机制,来保证正确。可以使用Schema或者是DTD来对xml的正确性进行校验。
6:基于xml配置的时候,只需要修改xml即可,不需要对现有的程序进行修改。
7:容易与其他系统进行数据交互。数据共享方便
Xml缺点
虽然上面列出了很多优点,但是xml也有缺点
1:应用程序中如果使用了xml配置,需要解析xml的工具或者是是第三方类库的支持;
2:解析xml的时候必然会占用资源,势必会影响到应用程序的性能;
以java为例,无论是将xml一次性装置到内存中,还是一行一行读取解析的,都会占用资源的。
3:xml配置文件过多,会导致维护变得困难
4:在程序编译期间无法对其配置项的正确性进行验证,只能在运行期发现。
5:出错后,排错变得困难。往往在配置的时候,一个手误就会出现莫名其妙的错误(虽然事出必有妖,但是排查真难);
比如,xml配置bean信息的时候,如果class的值带有空格,这种不好检查的,是比较麻烦的。排查起来很费事。
6:开发的时候,既要维护代码又要维护配置文件,使得开发的效率降低;
7:代码与配置项之间有时候会存在很多“潜规则”.改变了任意一方,都有可能影响到另一方的使用。这是个大坑
比如:自定义的标记,如果其他开发不清楚这些的话,修改了无论是代码还是xml的配置,都会导致程序不能正常运行。
8:开发工具对xml的验证支持的不是很好。
比如idea,对xml正确性,如果是自定义的,验证就不是很好。
说完xml的优缺点,我们在来看看注解的优缺点
注解优点
1:注解的解析可以不依赖于第三方库,可以之间使用Java自带的反射
2:注解和代码在一起的,之间在类上,降低了维护两个地方的成本
3:注解如果有问题,在编译期间,就可以验证正确性,如果出错更容易找
4:使用注解开发能够提高开发效率。不用多个地方维护,不用考虑是否存在“潜规则”
注解缺点:
1:修改的话比较麻烦。如果需要对注解进行修改的话,就需要对整个项目重新编译
2:处理业务类之间的复杂关系,不然xml那样容易修改,也不及xml那样明了
3:在程序中注解太多的话,会影响代码质量,代码简洁会有影响
4:如果后来的人对注解不了解,会给维护带来成本
5:注解功能没有xml配置齐全
简单总结下两者优缺点比较
注解:
优点:
简化配置
使用起来直观且容易,提升开发的效率
类型安全,容易检测出问题
缺点:
修改起来比xml麻烦
如果不项目不了解,可能给开发和维护带来麻烦
Xml:
优点:
把类与类之间松解偶;修改方便;容易扩展
容易和其他系统进行数据交互
对象之间的关系一目了然
缺点:
配置冗长,需要额外维护;影响开发效率
类型不安全,校验不出来,出错不好排查
注解简单概括:写起来比较简单、方便,看起来也简洁,但是修改麻烦
Xml配置概括:写起来比较灵活、修改方便,但是写和维护麻烦
大家还有什么更好的理解?欢迎分享出来

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Scratch高级编程之妙用变量管理母体与克隆体
一、 克隆简介 自从Scratch 2.0中引入克隆技术,程序中许多任务可以通过克隆技术更为高效地执行,而不再需要创建大量的精灵。克隆体实质上就是精灵的实例,这意味着它们继承了精灵的属性,但另一方面也是独立的对象。克隆体通常可能要执行与母体精灵稍有不同的任务,但一个关键的问题是:克隆体和母体精灵都对几乎所有事件块(触发器)能够做出响应。这样一来,专门为母体精灵设计的触发器在发出信号时也能够由克隆体运行。 实际开发中,当需要许多相似的精灵完成相似的任务时,就应该主动考虑到使用克隆技术。因为克隆是由程序而不是用户实现的,所以克隆的运用可以让用户不需要对许多精灵中的每个精灵进行相同的更改。因此,克隆技术可典型地应用于开发: 塔台防御小游戏(例如在地图上有大约200个塔台) 许多街机风格的游戏 子弹精灵(你想要多少就有多少,需要多少不同的角色就有多少) 复杂或半复杂粒子系统 烟火、雪等特效 鼠标轨迹 任何需要大量重复精灵的项目 【高级应用提示】Scratch中的克隆可以使用积木命令【当作为克隆体启动时】递归地克隆自身,有兴趣的朋友可作这方面更深入的探讨。 二、 借助变量管理母体与克隆体 先来看...
- 下一篇
【Go专家编程】5分钟玩转go.sum
为了确保一致性构建,Go引入了go.mod文件来标记每个依赖包的版本,在构建过程中go命令会下载go.mod中的依赖包,下载的依赖包会缓存在本地,以便下次构建。 考虑到下载的依赖包有可能是被黑客恶意篡改的,以及缓存在本地的依赖包也有被篡改的可能,单单一个go.mod文件并不能保证一致性构建。 为了解决Go module的这一安全隐患,Go开发团队在引入go.mod的同时也引入了go.sum文件,用于记录每个依赖包的哈希值,在构建时,如果本地的依赖包hash值与go.sum文件中记录得不一致,则会拒绝构建。 go.sum文件记录 go.sum文件中每行记录由module名、版本和哈希组成,并由空格分开: <module> <version>[/go.mod] <hash> 比如,某个go.sum文件中记录了github.com/google/uuid 这个依赖包的v1.1.1版本的哈希值: github.com/google/uuid v1.1.1 h1:Gkbcsh/GbpXz7lPftLA3P6TYMwjCLYm83jiFQZF/3gY= gith...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- 设置Eclipse缩进为4个空格,增强代码规范
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Red5直播服务器,属于Java语言的直播服务器
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2更换Tomcat为Jetty,小型站点的福音