V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
wangxin3
V2EX  ›  问与答

关于 Java 后端开发规范 Or 个人习惯?谈谈你们的理解和现有项目的状况。

  •  1
     
  •   wangxin3 · 2022-11-27 21:22:26 +08:00 · 1665 次点击
    这是一个创建于 486 天前的主题,其中的信息可能已经有所发展或是发生改变。

    这是我第一次在 V 站发帖,有点小激动啊! 先自我介绍一下,一个 Java 后端开发人员,三年+经验。现在有几个日常开发中遇到的问题,因为 V 站的大厂大佬比较多,所以想跟大家请教请教,希望大家可以谈谈自己的看法。

    问题 1 、在开发一个新功能时,我们定义好了具体的表模型,在定义 Controller 、Service 、Mapper 、...层的时候是怎么划分的。

    1. 严格按照表模型的粒度来划分的。比如:user 表,就有 UserController 、UserService...
    2. 是按照业务场景的粒度来划分的。比如:比如查询用户信息的业务场景(查询职务、职位、组织等等)需要四五张表才能支撑起来。定义一个统一的 UserDetailController 、UserDetailService...
    3. 以上两种混合使用。怎么方便怎么来。

    问题 2 、还是和 Service 和 Mapper 层有关,现有 AController 、AService 、AMapper 、BController 、BService 、BMapper 、...、ZMapper 。在注入相关对象的时候,有以下两种使用方式,你们使用哪种,或者有其他方式。

    1. AController -> AService -> AMapper ,BController -> BService -> BMapper
    2. AController -> BService -> CMapper ,BController -> AService -> CMapper

    层级:就是问题一中两种划分粒度,第一种是按表模型,第二种是按业务场景。

    第一种是严格注入,Controller 层只能注入本层级的 Service ,本层级的 Service 只能注入本层级的 Mapper ,本层级 Service “仅” 可以注入其他层级的 Service ,不能注入其他层级的 Mapper 。

    第二种就是比较随意,Contorller 层可以注入非本层级的 Service ,Service 也可以注入非本层级的 Mapper 。


    问题 3 、谈谈对单元测试的看法。

    1. 业务场景太复杂,100 行的业务代码,可能要写 500 行的单测代码,要 Mock 一大堆东西,有些抵触,个人更偏向于自己写完代码,自己调用接口,修修补补。也有可能代码功力不够,方法拆的不够小,导致单测代码比较难写。也知道单测对系统稳定性、低级 Bug 的发现有立竿见影的效果。
    2. 你的想法 /你们项目的做法。

    先说我自己习惯的使用场景吧。以上问题都是选第一种,可能我有强迫症?或许有些矫情?

    大家可以谈谈自己的习惯,和现有项目中的现状,让我学习学习[手动狗头]。

    以上仅仅是本人看法,不喜轻喷。

    10 条回复    2022-11-28 10:51:48 +08:00
    Terminator0826
        1
    Terminator0826  
       2022-11-27 22:28:33 +08:00 via Android   ❤️ 1
    怎么舒服怎么快怎么来吧,老板不理解的
    aecra1
        2
    aecra1  
       2022-11-27 23:45:07 +08:00 via Android
    1/2 你开始写得再好后面看的时候都觉得是屎山,如果不是那就是技术上没啥进步或者这个项目太稳定了
    3 函数写小函数,多写注释,有代码 review ,不测试流水账函数,测试又臭又长的业务函数没人想搞
    optional
        3
    optional  
       2022-11-28 00:00:42 +08:00 via iPhone
    按照 ddd 找聚合根的方法分 service
    oneisall8955
        4
    oneisall8955  
       2022-11-28 09:17:33 +08:00 via Android
    第一种太理想化了,少数业务需求才能单表 crud 。个人见解:业务的迭代,逻辑会越来越复杂,代码会越来越多。尽量保持一个类功能少一点,行数少一点,读起来也舒服点,这样也可以降低冲突概率,降低合并负担。
    wangxin3
        5
    wangxin3  
    OP
       2022-11-28 09:52:57 +08:00
    @Terminator0826 哈哈 可以的

    @optional 这样不会导致聚合的 service 最后太大吗。我现在是习惯把相关业务有关的 service 就放到具体和数据库表模型对应的 service 中,有点聚合根的意思,但是没有新建 controller 、service 做这些事情。

    @aecra1 学到了 第三个问题,确实是我要改正加强的地方

    @oneisall8955 可能我没有描述清楚,我们的业务肯定不是单表 crud ,肯定是有相互注入的,我的意思是不是要新建聚合的 service ,还是把相关逻辑放到具体表模型的业务类中。
    zoyua
        6
    zoyua  
       2022-11-28 10:24:41 +08:00
    你应该是缺了一层,controller -> manager -> service -> mapper
    wangxin3
        7
    wangxin3  
    OP
       2022-11-28 10:28:58 +08:00
    @zoyua #6 原文:“你应该是缺了一层,controller -> manager -> service -> mapper”
    ======
    回复:那么 controller 和 manager 是聚合业务的吗,service 和 mapper 操作单表的?
    optional
        8
    optional  
       2022-11-28 10:30:47 +08:00 via iPhone
    @wangxin3 写进去确实会很大,尝试过把一些操作拆出来放到 domain service ,domain service 本质上是 static method 集合(实际放 spring 还是 non static 只是没有外部依赖),只负责操作相关的 data model (因为不想搞 ddd 充血模型那一套,还是搞成类似扩展方法的形式),这样的好处是单元测试简单,按顺序加锁都不会有问题
    wangxin3
        9
    wangxin3  
    OP
       2022-11-28 10:34:43 +08:00
    @zoyua #6 原文:“你应该是缺了一层,controller -> manager -> service -> mapper”
    ======
    回复:刚查了下。阿里开发手册定义的 manager 层是介于 service 和 mapper 之间的。
    Manager 层:通用业务处理层,它有如下特征:一是对第三方平台封装的层,预处理返回结果及转化异常信息;二是对 Service 层通用能力的下沉,如缓存方案、中间件通用处理;三是与 DAO 层交互,对多个 DAO 的组合复用。
    amwyyyy
        10
    amwyyyy  
       2022-11-28 10:51:48 +08:00
    我之前待过一家公司是有讲究的,要控制好分层和 service 的调用关系。不过现在都是微服务,单个应用业务不会太复杂也没有很多的类,就比较随意了。
    单元测试作用挺大的,就是项目没给时间写,也不要求,所以我做过的项目 99%都没有写。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5432 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 08:10 · PVG 16:10 · LAX 01:10 · JFK 04:10
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.