开发中一定需要 service 接口和 serviceImpl 吗
感觉不用接口直接写实现开发更加方便
1
Lxxyx 2019-08-17 11:00:19 +08:00 via iPhone
这样做的好处可以很容易实现依赖反转。直接写虽然方便,但是底层依赖发生变动时,改代码会很痛苦
|
2
cheng6563 2019-08-17 11:00:58 +08:00 via iPhone
不用,三层架构的业务层基本不可能多态,写个接口没啥意义
|
3
niubee1 2019-08-17 11:06:11 +08:00 2
说是为了应对底层变动, 结果底层换数据库是不可能换数据库的, 辛辛苦苦写了一大堆为了应付变动的代码, 结果整个项目周期,除了需求, 啥也没动.........
|
4
micean 2019-08-17 11:07:17 +08:00
本来是要的,因为 java 本身用代理功能需要 interface
但是后面 spring 用 cglib 做动态代理了,直接修改字节码,也就不需要强制这套写法了 |
5
cyssxt 2019-08-17 11:12:11 +08:00 via iPhone
没有必要。我觉得这个是上个时代的代理的方式导致的。
|
6
zjsxwc 2019-08-17 11:14:30 +08:00
大部分项目业务从开始到结束也只有一个 serviceImpl
只是为了遵循约定,每个业务都写一个 service 接口和一个 serviceImpl |
7
vincel 2019-08-17 11:15:08 +08:00
这是企业级的架构 当然你项目规模没那么大就不需要了
|
8
sorra 2019-08-17 11:40:27 +08:00 4
模块化开发是需要的,分成 API 包和 impl 包,别人只需要依赖你的 API 包
|
9
passerbytiny 2019-08-17 11:46:57 +08:00
十年前,一定要;现在,一定不要:现在见到这种代码要三思,见到强制要求这种风格的要跑路。
|
10
orangeD 2019-08-17 11:52:42 +08:00 via Android
完全没有必要。就算万一有要用到接口,现在 IED 的重构功能也可以很方便地抽出接口
|
11
luckylo 2019-08-17 12:02:18 +08:00 via Android
就多一个 service 接口都在说了,我司遗留代码 mapper 层直接操作数据库,dao 层直接操作 mapper 层,就直接操作,没其他函数封装,service 层操作 dao 层,这里才有封装,封装还不彻底,controller 层都有看到直接调用 mapper 层的,反正代码非常乱。
|
12
nicevar 2019-08-17 12:06:12 +08:00
具体得看是什么项目了,你自己的项目随便整都行,公司的项目就得注意了
|
13
Bromine0x23 2019-08-17 12:38:40 +08:00
大部分情况下确实没啥必要,但是还是会自觉地这么做,迫使自己思考这个 Service 的职责,Service 的功能也能展示得清楚些
|
14
tachikomachann 2019-08-17 12:40:51 +08:00 via Android 1
按现在大行其道的微服务的话,我觉得是没必要。。
|
15
NeinChn 2019-08-17 12:52:04 +08:00
如果只有一种实现,可以不做,但是一定要区分好 public 和 private/protect 方法,避免内部私有逻辑被其他人调用
如果有多重实现,你觉得呢,难不成搞个 duck type 的概念,基于反射调用同名方法么,Python 不适合协作开发也不是一天两天的事情了,不要写的像 Python 就行. |
16
daozhihun 2019-08-17 14:38:52 +08:00
如果是公司长久的项目,建议分开。
这个东东对自动化测试还是很有用的。 |
17
JRay 2019-08-17 14:40:46 +08:00
之前我也想过这个东西有没有必要,现在公司直接放弃 serviceImpl 了
|
18
StarkWhite 2019-08-17 16:36:35 +08:00 1
每个业务写一个 Service 和 ServiceImpl,即便操作同一张表,别人也不会复用你的,甚至自己在其它业务也不会复用。
方便单元测试?有几个项目真正把单元测试落实的?需求总在变,测试代码经常跑不通也得一起改,加班加点业务需求都忙不完还有时间管单元测试? 敏捷开发原则之一:简单的方法就是好的方法 过早优化是万恶之源,不要在不确定的情况下加入不必要的复杂性 |
19
StarkWhite 2019-08-17 16:44:08 +08:00 1
controller -> manager -> service -> dao -> mapper
manager, service, dao 大部分都是重复的代码,一个方法,里面就一行,调用下一层的同名方法,业务都是 SQL 实现, 一堆功能几乎重复文件看着就头疼,调代码跳来跳去也烦 |
20
StarkWhite 2019-08-17 16:51:32 +08:00
业务真要改了,不都是改业务逻辑代码?所谓的被依赖和复用大部分都是拍脑袋凭空想象,就自己写的那一个接口依赖了而已,既然都是自己写的,不写冗余的类和接口,代码更少不是更容易改?
|
21
cabing 2019-08-17 17:06:42 +08:00
大部分情况是没有必要。但是评估下项目的重要性和生存时间,迁移的可能性。
有时这种抽象真的是很有用,特别是迁移。 |
22
lihongjie0209 2019-08-17 17:45:58 +08:00 4
看你写代码的方式了, 比如说我一般从 controller 开始写, 这时候我需要依赖一个 service, 最简单的方式就是创建一个 interface, 然后接着把 controller 的逻辑写完. 最后实现这个 interface.
也就是自顶向下的实现了. 如果你是从 dao 开始写, 那么确实没有什么必要 |
23
srx1982 2019-08-17 18:45:11 +08:00
反正我一般不写
|
24
xalilo 2019-08-17 22:45:33 +08:00
@lihongjie0209 从 controller 开始写,空的 Impl 方法也不影响你操作啊
|
25
zhuifeng1017 2019-08-18 00:04:28 +08:00
表结构定义好后,controller,service,mapper,entity 都代码自动生成了,不要太简单。自己写的代码没几行
|
26
lihongjie0209 2019-08-18 10:32:24 +08:00
@xalilo #24 你这么说也可以, 看个人习惯
|
27
GiantHard 2019-08-18 10:49:29 +08:00
如果你不需要单元测试,就不需要使用接口
|
28
cnzjl 2019-08-18 16:28:15 +08:00
现在没啥必要吧,改的时候也烦,改完 interface 改 impl。
|
29
james122333 2019-08-18 21:10:16 +08:00
我只写两层 controller service
mapper entity 的就是把事情复杂化而已 两层分刚刚好 还可以很容易前后端分离、混合双用 |
30
taaaang 2019-08-19 08:45:59 +08:00
没必要,个别类考虑到多态的可以写。interface 是个好东西,但前提是不滥用。
|
32
9Rubi 2019-08-19 11:15:10 +08:00
多 profile ,这就很有必要了。
|
33
luckylo 2019-08-19 11:15:16 +08:00 via Android
@BeFun 还有,代码不复用,一个 service 实现类 10000+行代码,如果真需要接口,完全可以拆成多个实现类,代码少一点,同一个类函数调用的跳转也会舒服点。个人觉得,接口存在的必要是方便多个实现类存在的,不然 java 的多态就是一句空话。既然不会存在多个实现,还写一堆无用代码,打包时间变长不说,最主要的是影响阅读
|
34
vanishxiaoma OP 好吧, 被客户要求必须要有 service 接口了
|
35
luckymao 2019-09-05 17:54:34 +08:00
我觉得在协作开发时先写接口还是好的,不然别人写的时候都没有接口可调用如何继续写下去呢
|
36
vitoaaazzz 2020-05-29 17:12:24 +08:00
@passerbytiny
10 年前为什么一定要?能不能详细说下,多谢。 |