Java 项目中对于单一的特定 DB 操作需要用 Service 层包装吗？

[lawsiki]

抛开 BaseService 这种封装了通用操作的类，对于一些特定的更新或查询

比如一个复杂的 SQL，但是只有一个接口会使用，这个时候是需要包装一层 Service，在 Controller 调用 Service，还是直接在 Controller 中注入 Dao 使用？（专业名词好像叫穿层？？）

[chendy]

DB 操作和 service 无关，service 是业务不是数据库操作
至于要不要给 Controller 注入 dao，对于一次性的 /简单的 /无所谓的东西，直接在 controller 里写 sql 都无所谓，否则老老实实分层

[lawsiki]

@chendy #1 恩，我也是这么想的，但是这样就会存在 Controller 中同时存在 OrderService，OrderMapper 两种，就感觉比较乱，所以看看有没有什么比较优雅的解决方法

[banjueaz]

有一层 Service 的话，以后要维护加逻辑就可以在 service 加

[paranoiddemon]

在 controller 注入 mapper 不是很优雅

[golangLover]

@chendy 不太明白“DB 操作和 service 无关，service 是业务不是数据库操作”
你的意思是 service 里面直接用 dao 不是很好？

[amoyiki]

多写一层 Service 是为了后期修改数据逻辑方便
多个调用只需要改一次 Service 层的方法即可，
如果 Controller 层直接从数据库中获取数据，后期修改可能就要改多个地方了

[xy90321]

分层的意义在于划分职责，跟职责大小无关
如果按照所谓职责大小分的话，那就是没有量化标准、随心所欲的分层了

[clf]

我是这样认为的：Dao 层是统一的数据控制，Service 层是不同数据间的业务关系的处理。

比如下面的几种情况：
1.某个类的某些字段不允许为空。那么校验方法是在 Dao 层提供的，并且在 insert 和 update 时强制性调用这个方法去校验数据。

2.某个类的数据库应该是 A 数据库，另外一个类是 B 数据库，多数据源时 Service 层不应该关心这个，这些也是 Dao 层去配置和处理的。

3.业务需要逻辑删除，Dao 层在处理 Service 层传入的查询条件时，自动加上逻辑删除的判断条件（如果需要读“被删除”的数据，则额外提供接口），在保存 /删除 /更新数据时，自动处理为逻辑删除的方式。

[lawsiki]

@amoyiki #6 但像我说的这种情况，其实就没有后期修改的一个问题，都是一些特定场景下的 SQL

[beneo]

不需要那么多里理由。

你自己做 UT 么，你不做你就不需要 serive

[JamChiu]

如果是一次性的项目，怎么快怎么来(编码洁癖除外)，如果是企业级项目，建议还是乖乖搞个 Service 吧

[kimifdw]

就看这个 DB 操作是否需要做进一步的业务处理，如果不需要 controller 直接操作 DB 也未尝不可。具体还是要看实际场景，controller-service-dao 并不是一尘不变的

[lawsiki]

@lychs1998 #8 这个没毛病，主要就是想偷点懒，而且一个不涉及任何逻辑的 dao 操作都要包一层 service 就有点难受 😂

[wiix]

最务实的做法是需要事务支持的时候才用 service 。controller 中既存在 repo 又存在 service 的问题可以通过抽象 baseRepo 和 baseService 这种方式解决。通过简单的抽象就可以做到基础操作全在 baseService 中进行。复杂操作也没理由不用 service 和事务了。

[ikas]

如果你用的 spring,通常 service 不仅是作为一个业务 /功能单元,还是保证业务正确的事务单元..
假设你将 dao 直接注入 controller,那么你的 dao 就需要自己处理异常 /回滚.如果你的 dao 中有两条 db 操作,那么你自己处理事务的代码,还不如写个 service 方便

[xuanbg]

省又能省几行代码？写那几行 Interface 代码要 5 分钟嘛？再说，写了 Interface，Impl 就能直接生成方法了，不然你还不得手写？

[linyinma]

Spring 这套核心思想：面向接口编程， 分层只是一种抽象，假如这个 service 不存在后期扩展 /外部调用， 死板的加一层有何毛用，

[keepcleargas]

不为分层而分层，按业务模块的 聚合 来写，对外无影响 对内提供便捷 何乐而不为。

[powerman]

看项目吧，如果是垃圾项目 直接一杆子捅到底，没有任何分层的必要，大不了复制粘贴一下，反正这种代码也活不长

[shanghai1943]

如果不知道咋整的话，就老老实实 controller+service+dao 吧。免得纠结以及日后维护的人不适应。