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