评论

收藏

[NoSQL] Service层需求接口

数据库 数据库 发布于:2021-12-21 22:25 | 阅读数:490 | 评论:0

今天我们要讨论的问题是:Service层需求接口?
如今分离我参与的项目以及阅读的一些项目源码来看。假如**「项目中运用了像Spring这样的依赖注入框架,那能够不用接口」**!
先来说说为什么运用了依赖注入框架以后,能够不运用接口!

不需求接口的理由
我整理了支持Service层和Dao层需求加上接口的理由,总结下来就这么三个:



  • 能够在尚未完成详细Service逻辑的状况下编写上层代码,如Controller对Service的调用
  • Spring默许是基于动态代理完成AOP的,动态代理需求接口
  • 能够对Service停止多完成


实践上,这三个理由都站不住脚!
先说说第一个理由:「上层能够在下层逻辑没有完成的状况下停止编码」!很典型的面向接口编程,对层与层之间停止理解耦,看起来仿佛没有问题。
这种开发方式合适不同模块之间是由不同的人或项目组开发的,由于沟通的本钱比拟大。同时防止由于项目组之间开发进度的差别而互相影响。
不过让我们回想一下,在普通项目开发里面,有几项目组是按层来切分开发任务的呢?实践上,大局部的项目都是依照功用划分的。即便是如今前后端别离的状况,单纯的后端开发也是依照功用模块停止任务划分,即一个人担任从Controller层到DAO层的完好逻辑处置。在这种状况下,每一层都先定义一个接口,再去完成逻辑,除了增加了开发人员的工作量(当然,假如代码量计入工作量的话,那开发人员应该也不是太排挤接口的!),实践没有任何用途。
假如开发人员想在下层逻辑没有完成的状况下,先开发上层逻辑,能够先编写下层类的空办法来先完成上层的逻辑。
这里引荐一个个人比拟喜欢的开发流程,自上向下的编码流程:



  • 先在Controller层编写逻辑,遇到需求拜托Service调用的中央,直接先写出调用代码。优先完成Controller层的流程
  • 然后运用IDE的自动补全,对方才调用下层的代码生成对应的类和办法,在里面添加TODO
  • 等一切的类和办法都补全了,再基于TODO,依照上面的流程去一个个的完善逻辑。


此办法能够使你对业务流程有比拟好的了解。
关于第二个理由,就完整不成立了。Spring默许是基于动态代理的,不过经过配置是能够运用CGLib来完成AOP。CGLib是不需求接口的。
最后一个理由是「能够对Service停止多完成」。这个理由不充沛,或者说没有思索场景。实践上在大多数状况下是不需求多完成,或者说能够运用其它方式替代基于接口的多完成。
另外,关于很多运用了接口的项目,项目构造也是有待商榷的!下面,我们分离项目构造来阐明。

项目构造与接口完成
普通项目构造都是按层来划分的,如下所示:



  • Controller
  • Service
  • Dao






关注下面的标签,发现更多相似文章