Java 中 Service 层和 DAO 层有必要每个类都加上接口吗?

>>号外:关注“Java精选”公众号,回复“2021面试题”,领取免费资料!“Java精选面试题”小程序,3000+ 道面试题在线刷,最新、最全 Java 面试题!

前几天刷头条又刷到了「Service层和Dao层真的有必要每个类都加上接口吗?」这个问题,之前简单回答了一波,给出的观点是「看情况」!

现在结合我参与的项目以及阅读的一些项目源码来看。如果项目中使用了像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

对于不需要多实现的情况,也就不需要接口了。上面的项目结构即可满足要求。

对于需要多实现的情况,无论是现在需要,还是后面需要。这种情况下,看起来好像是需要接口。此时的项目结构看起来像这样:

  • Controller

  • Service

    • ----接口在一个包中

    • impl ---实现在另一个包里

  • Dao

对于上面的结构,我们来考虑多实现的情况下,该怎么处理?

第一种方式,是在Service中新增一个包,在里面编写新的逻辑,然后修改配置文件,将新实现作为注入对象。

  • Controller

  • Service

    • ---- 接口在一个包中

    • impl ---实现在另一个包里

    • impl2 ---新实现在另一个包里

  • Dao

第二种方式,是新增一个Service模块,在里面编写新的逻辑(注意这里的包和原来Service的包不能相同,或者包相同,但是类名不同,否则无法创建类。因为在加载时需要同时加载两个Service模块,如果包名和类名都相同,两个模块的类全限定名就是一样的了!),然后修改配置文件,将新逻辑作为注入对象。

  • Controller

  • Service

    • ---- 接口在一个包中

    • impl ---实现在另一个包里

  • Service2

    • impl2 ---新实现在另一个包里

  • Dao

相对而言,实际第一种方式相对更简单一点,只需要关注包层面。而第二种方式需要关注模块和包两个层面。另外,实际这两种方式都导致了项目中包含了不需要的逻辑代码。因为老逻辑都会被打进包里。

不过,从结构上来看,实际方式二的结构要比方式一的结构更清晰,因为从模块上能区分逻辑。

那有没有办法来结合两者的优点呢?答案是肯定的,而且操作起来也不复杂!

首先将接口和实现独立开,作为一个独立的模块:

  • Controller

  • Service --- 接口模块

  • ServiceImpl

    • impl ---实现在另一个包里

  • ServiceImpl2

    • impl2 ---新实现在另一个包里

  • Dao

其次,调整打包配置,ServiceImpl和ServiceImpl2二选一。既然ServiceImpl和ServiceImpl2是二选一,那ServiceImpl和ServiceImpl2的包结构就可以相同。包结构相同了,那调整了依赖以后,依赖注入相关的配置就不需要调整了。调整后,项目结构看起来像这样:

  • Controller

  • Service --- 接口模块

  • ServiceImpl

    • impl ---实现在另一个包

  • ServiceImpl2

    • impl ---新实现和老实现在相同的包中

  • Dao

现在,ServiceImpl和ServiceImpl2模块中的包结构、类名都是一样的。那我们还需要接口模块吗?

假设,我们把Service接口模块去掉,结构变成了如下所示:

  • Controller

  • Service1 --- 老实现

  • Service2 --- 新实现

  • Dao

单纯的通过调整模块依赖,是否能实现Service的多实现?答案显而易见吧?

不使用接口的缺点

上面给出了不使用接口的理由。不过不使用接口并不是完全没有缺点的,主要问题就是在进行多实现的时候,没有一个强接口规范。即不能通过实现接口,借助IDE快速生成框架代码。对于没有实现的接口,IDE也能给出错误提醒。

一个不太优雅的解决是,将原来的模块里的代码拷贝一份到新模块中,基于老代码来实现新的逻辑。

所以,如果一个项目需要多实现、且多实现数量较多(不过一般项目不会有多个实现的),则推荐使用接口。否则不需要使用接口。

总结

本文针对「Service层是否需要接口」这个问题,指出需要接口的理由的问题。以及个人对这个问题的观点,希望对大家有一些帮助。

作者:架构思维

toutiao.com/i6882356844245975563

往期精选  点击标题可跳转

美团实习面试:熟悉红黑树是吧?能不能写一下?说一说空间和时间复杂度?

Spring Boot 集成 WebSocket,实现前后端即时通讯,如此简单!

Spring Boot 接口频繁超时,Alibaba 开源 Arthas 精准定位 BUG 问题!

踩坑!Spring 事务方法与非事务方法相互调用 @Transactional 注解失效不回滚?

Spring Boot 中如何实现 Mybatis 逆向工程,你 GET 到了吗?(附源码)

你了解 JDK 8 Stream 数据流效率吗?千万级数据量性能如何?

Spring 中毒太深,离开 Spring 居然连最基本的接口都不会写了!

Spring Boot 线程池的使用心得,你真会用吗?

从原理到实践彻底搞懂 Java 日志系统,再也不迷茫了!

如何设计 QQ、微信、微博、Github 等第三方账号登陆 ?(附表设计)

【源码解读】JDK1.8 中 ConcurrentHashMap 不支持空键值对源码剖析

点个赞,就知道你“在看”!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Struts2、Hibernate、Spring整合的泛型DAO (本人评价: 代码开发效率提高30% 代码出错率减少70%) 对于大多数开发人员,系统每个 DAO 编写几乎相同的代码到目前为止已经成为一种习惯。虽然所有人都将这种重复标识为 “代码味道”,但我们大多数都已经学会忍受它。能不能不写重复的dao 呢 ? 泛型dao,顾名思义就是一个dao可以对多个实体对象进行持久化。当应用需要使用到上十张表时,DAO的维护变得日益困难,主要表现在这几个方面: 1)dao的繁多,很多设计都是一个entity对应一个dao (不同的只有名和方法名) 2)dao接口需要维护的method庞大。 3)业务逻辑改变时,dao需要同时修改两个文件(接口和实现) 在本文,我将为您展示如何避免再三地重复 DAO 代码。 在这里我建议项目最好使用一个共通的DAO,因为这样会为你省去非常多的,而那些里的逻辑往往差不多。当然是用共通的DAO需要对结果转型,转成你需要的bean,但这也比写那么多DAO强多了,你可以放下包袱,只关注你的业务逻辑。 如果你真能只用一个dao解决,那么祝贺你,你得到了一个虚拟数据(高度抽象的数据接口)。这是一个比dao更高级的存在。 欢迎大家指正 -_- 虚心求教 代码次: bean-->dao-->service-->action 技术概述:1.继承 继承是利用现有的创建新的过程,现有的称作基(或父),创建的新称作派生(子)。继承其实就是自动地共享基成员属性和成员方法的机制。引入继承,实现了代码重用; 2.泛型 泛型型的限定 3.反射 代码概述: bean :Person.java 这个人员我就不说了 泛型dao接口 :GenericDao<T, ID extends Serializable> 泛型作为DAO的通用接口 CRUD方法 dao接口 : PersonDAO extends GenericDao<Person, Integer> 可以不写代码,方法已经在父泛型dao里了,这里为了说明:可扩展添 findByNameExact()方法 子的附方法。 泛型daoimpl :GenericDaoImpl<T, ID extends Serializable> implements GenericDao<T, ID> 必须提供的构造方法,以便创建实例的时候就知道具体实体的型。 daoimpl :PersonDAOImpl extends GenericDaoImpl<Person, Integer> implements PersonDAO public PersonDAOImpl() { super(Person.class); } 告诉对哪个操作,如不需要自定义扩展方法就作有一个构造方法。 泛型Service:GenericService.java 与泛型dao没有区别 Service :PersonService.java 直接继承。 泛型serviceimpl与serviceimpl实现和dao实现一样。 Action : SavePersonAction直接调用PersonService。 下面是代码 为了演示减少代码量而且直观去掉些方法方便读者自己扩展写出适合自己的代码,这里我只抛砖引玉了。主要介绍这个技术。 本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/zylyueliang/archive/2010/09/17/5890043.aspx

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值