V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lawsiki
V2EX  ›  程序员

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

  •  1
     
  •   lawsiki · 99 天前 · 2182 次点击
    这是一个创建于 99 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    23 条回复    2021-08-30 11:57:51 +08:00
    chendy
        1
    chendy  
       99 天前
    DB 操作和 service 无关,service 是业务不是数据库操作
    至于要不要给 Controller 注入 dao,对于一次性的 /简单的 /无所谓的东西,直接在 controller 里写 sql 都无所谓,否则老老实实分层
    lawsiki
        2
    lawsiki  
    OP
       99 天前
    @chendy #1 恩,我也是这么想的,但是这样就会存在 Controller 中同时存在 OrderService,OrderMapper 两种,就感觉比较乱,所以看看有没有什么比较优雅的解决方法
    banjueaz
        3
    banjueaz  
       99 天前
    有一层 Service 的话,以后要维护加逻辑就可以在 service 加
    paranoiddemon
        4
    paranoiddemon  
       99 天前 via Android
    在 controller 注入 mapper 不是很优雅
    golangLover
        5
    golangLover  
       99 天前
    @chendy 不太明白“DB 操作和 service 无关,service 是业务不是数据库操作”
    你的意思是 service 里面直接用 dao 不是很好?
    amoyiki
        6
    amoyiki  
       98 天前
    多写一层 Service 是为了后期修改数据逻辑方便
    多个调用只需要改一次 Service 层的方法即可,
    如果 Controller 层直接从数据库中获取数据,后期修改可能就要改多个地方了
    xy90321
        7
    xy90321  
       98 天前 via iPhone
    分层的意义在于划分职责,跟职责大小无关
    如果按照所谓职责大小分的话,那就是没有量化标准、随心所欲的分层了
    clf
        8
    clf  
       98 天前
    我是这样认为的:Dao 层是统一的数据控制,Service 层是不同数据间的业务关系的处理。

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

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

    3.业务需要逻辑删除,Dao 层在处理 Service 层传入的查询条件时,自动加上逻辑删除的判断条件(如果需要读“被删除”的数据,则额外提供接口),在保存 /删除 /更新数据时,自动处理为逻辑删除的方式。
    lawsiki
        9
    lawsiki  
    OP
       98 天前
    @amoyiki #6 但像我说的这种情况,其实就没有后期修改的一个问题,都是一些特定场景下的 SQL
    beneo
        10
    beneo  
       98 天前
    不需要那么多里理由。

    你自己做 UT 么,你不做你就不需要 serive
    JamChiu
        11
    JamChiu  
       98 天前
    如果是一次性的项目,怎么快怎么来(编码洁癖除外),如果是企业级项目,建议还是乖乖搞个 Service 吧
    kimifdw
        12
    kimifdw  
       98 天前
    就看这个 DB 操作是否需要做进一步的业务处理,如果不需要 controller 直接操作 DB 也未尝不可。具体还是要看实际场景,controller-service-dao 并不是一尘不变的
    lawsiki
        13
    lawsiki  
    OP
       98 天前
    @lychs1998 #8 这个没毛病,主要就是想偷点懒,而且一个不涉及任何逻辑的 dao 操作都要包一层 service 就有点难受 😂
    wiix
        14
    wiix  
       98 天前
    最务实的做法是需要事务支持的时候才用 service 。controller 中既存在 repo 又存在 service 的问题可以通过抽象 baseRepo 和 baseService 这种方式解决。通过简单的抽象就可以做到基础操作全在 baseService 中进行。复杂操作也没理由不用 service 和事务了。
    ikas
        15
    ikas  
       98 天前
    如果你用的 spring,通常 service 不仅是作为一个业务 /功能单元,还是保证业务正确的事务单元..
    假设你将 dao 直接注入 controller,那么你的 dao 就需要自己处理异常 /回滚.如果你的 dao 中有两条 db 操作,那么你自己处理事务的代码,还不如写个 service 方便
    xuanbg
        16
    xuanbg  
       98 天前
    省又能省几行代码?写那几行 Interface 代码要 5 分钟嘛?再说,写了 Interface,Impl 就能直接生成方法了,不然你还不得手写?
    linyinma
        17
    linyinma  
       98 天前
    Spring 这套核心思想:面向接口编程, 分层只是一种抽象,假如这个 service 不存在后期扩展 /外部调用, 死板的加一层有何毛用,
    keepcleargas
        18
    keepcleargas  
       98 天前
    不为分层而分层,按业务模块的 聚合 来写,对外无影响 对内提供便捷 何乐而不为。
    powerman
        19
    powerman  
       98 天前
    看项目吧,如果是垃圾项目 直接一杆子捅到底,没有任何分层的必要,大不了复制粘贴一下,反正这种代码也活不长
    shanghai1943
        20
    shanghai1943  
       98 天前
    如果不知道咋整的话,就老老实实 controller+service+dao 吧。免得纠结以及日后维护的人不适应。
    LearnFeedback
        21
    LearnFeedback  
       98 天前
    第一、我认为按照项目组制定的规范来
    第二、没有规范是按照自己的规范来 最好是按照分层来
    第三、实际分层的目的还是为了代码的复用和职责的划分
    ckdxc
        22
    ckdxc  
       98 天前
    建议 还是加上 service, 以后万一要加功能的话,可以在 service 直接加, 要不然下次 别人还是会加, 别人就会考虑是否要把你的方法移回 service
    newmlp
        23
    newmlp  
       98 天前
    service 是业务层,不是用来包装数据库操作的,业务层又不一定需要操作数据库
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4131 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 06:30 · PVG 14:30 · LAX 22:30 · JFK 01:30
    ♥ Do have faith in what you're doing.