开发中一定需要 service 接口和 serviceImpl 吗

这样做的好处可以很容易实现依赖反转。直接写虽然方便，但是底层依赖发生变动时，改代码会很痛苦

不用，三层架构的业务层基本不可能多态，写个接口没啥意义

说是为了应对底层变动， 结果底层换数据库是不可能换数据库的， 辛辛苦苦写了一大堆为了应付变动的代码， 结果整个项目周期，除了需求， 啥也没动.........

本来是要的，因为 java 本身用代理功能需要 interface
但是后面 spring 用 cglib 做动态代理了，直接修改字节码，也就不需要强制这套写法了

没有必要。我觉得这个是上个时代的代理的方式导致的。

大部分项目业务从开始到结束也只有一个 serviceImpl
只是为了遵循约定，每个业务都写一个 service 接口和一个 serviceImpl

这是企业级的架构 当然你项目规模没那么大就不需要了

模块化开发是需要的，分成 API 包和 impl 包，别人只需要依赖你的 API 包

十年前，一定要；现在，一定不要：现在见到这种代码要三思，见到强制要求这种风格的要跑路。

完全没有必要。就算万一有要用到接口，现在 IED 的重构功能也可以很方便地抽出接口

就多一个 service 接口都在说了，我司遗留代码 mapper 层直接操作数据库，dao 层直接操作 mapper 层，就直接操作，没其他函数封装，service 层操作 dao 层，这里才有封装，封装还不彻底，controller 层都有看到直接调用 mapper 层的，反正代码非常乱。

具体得看是什么项目了，你自己的项目随便整都行，公司的项目就得注意了

大部分情况下确实没啥必要，但是还是会自觉地这么做，迫使自己思考这个 Service 的职责，Service 的功能也能展示得清楚些

按现在大行其道的微服务的话，我觉得是没必要。。

如果只有一种实现,可以不做,但是一定要区分好 public 和 private/protect 方法,避免内部私有逻辑被其他人调用
如果有多重实现,你觉得呢,难不成搞个 duck type 的概念,基于反射调用同名方法么,Python 不适合协作开发也不是一天两天的事情了,不要写的像 Python 就行.

如果是公司长久的项目，建议分开。
这个东东对自动化测试还是很有用的。

之前我也想过这个东西有没有必要，现在公司直接放弃 serviceImpl 了

每个业务写一个 Service 和 ServiceImpl，即便操作同一张表，别人也不会复用你的，甚至自己在其它业务也不会复用。
方便单元测试？有几个项目真正把单元测试落实的？需求总在变，测试代码经常跑不通也得一起改，加班加点业务需求都忙不完还有时间管单元测试？
敏捷开发原则之一：简单的方法就是好的方法
过早优化是万恶之源，不要在不确定的情况下加入不必要的复杂性

controller -> manager -> service -> dao -> mapper
manager, service, dao 大部分都是重复的代码，一个方法，里面就一行，调用下一层的同名方法，业务都是 SQL 实现，
一堆功能几乎重复文件看着就头疼，调代码跳来跳去也烦

业务真要改了，不都是改业务逻辑代码？所谓的被依赖和复用大部分都是拍脑袋凭空想象，就自己写的那一个接口依赖了而已，既然都是自己写的，不写冗余的类和接口，代码更少不是更容易改？

大部分情况是没有必要。但是评估下项目的重要性和生存时间，迁移的可能性。

有时这种抽象真的是很有用，特别是迁移。

看你写代码的方式了, 比如说我一般从 controller 开始写, 这时候我需要依赖一个 service, 最简单的方式就是创建一个 interface, 然后接着把 controller 的逻辑写完. 最后实现这个 interface.
也就是自顶向下的实现了.

如果你是从 dao 开始写, 那么确实没有什么必要

反正我一般不写

@lihongjie0209 从 controller 开始写，空的 Impl 方法也不影响你操作啊

表结构定义好后，controller，service，mapper，entity 都代码自动生成了，不要太简单。自己写的代码没几行

@xalilo #24 你这么说也可以， 看个人习惯

如果你不需要单元测试，就不需要使用接口

我只写两层 controller service
mapper entity 的就是把事情复杂化而已
两层分刚刚好 还可以很容易前后端分离、混合双用

没必要，个别类考虑到多态的可以写。interface 是个好东西，但前提是不滥用。

@luckylo 一样一样，五六年前的代码改的非常累

多 profile ,这就很有必要了。

@BeFun 还有，代码不复用，一个 service 实现类 10000+行代码，如果真需要接口，完全可以拆成多个实现类，代码少一点，同一个类函数调用的跳转也会舒服点。个人觉得，接口存在的必要是方便多个实现类存在的，不然 java 的多态就是一句空话。既然不会存在多个实现，还写一堆无用代码，打包时间变长不说，最主要的是影响阅读

好吧, 被客户要求必须要有 service 接口了

我觉得在协作开发时先写接口还是好的，不然别人写的时候都没有接口可调用如何继续写下去呢

@passerbytiny
10 年前为什么一定要？能不能详细说下，多谢。