这是一个创建于 530 天前的主题，其中的信息可能已经有所发展或是发生改变。
1.先写 DAO -> 再写 Service -> 然后写 Controller
2.先写 Controller -> 再写 Service -> 然后写 DAO
个人已经习惯第二种写法了, 是不是第一种更好
2.先写 Controller -> 再写 Service -> 然后写 DAO
个人已经习惯第二种写法了, 是不是第一种更好
22 条回复 2024-11-05 12:03:48 +08:00
 | 1 swim2sun 2024 年 10 月 26 日 让 AI 帮你一次性都写好 （ |
 | 3 beginor 2024 年 10 月 26 日 via Android 用代码生成器，一次全搞定，别纠结 |
 | 4 maix27 2024 年 10 月 26 日 第二层舒服点吧。 |
 | 5 sagaxu 2024 年 10 月 26 日 先写哪个都行。 我一般按照数据流向来写，Controller -> Service -> DAO ，Controller 写完可以先发布到测试环境给前端调调看了 |
 | 6 lyusantu 2024 年 10 月 26 日 走一步看一步就是 2 提前规划就是 1 |
 | 7 fanchenio 2024 年 10 月 26 日 按照你自己的思路写就行，哪步开始都可以，我是 Service -> DAO -> Controller 。 |
 | 先定义 api spec ，然后生成脚手架。业务逻辑可以自己写。 |
 | 9 prosgtsr 2024 年 10 月 26 日 via iPhone 我是 service-dao-controller |
 | 10 proxychains 2024 年 10 月 26 日 dao -> service -> controller |
 | 11 markgor 2024 年 10 月 26 日 dao -> service -> controller -> service -> dao -> controller -> ... loop |
 | 12 lsry 2024 年 10 月 26 日 controller 可以快和前端接，短 |
 | 13 vyuai OP 感谢各位大佬 |
 | 14 DIO 2024 年 10 月 28 日 如果设计完备，就从底层写起，其他情况就是界面需要啥现场手搓 |
 | 15 qloog 2024 年 10 月 28 日 dao -> service -> controller 先有数据模型，再写业务逻辑，最后写参数检查和调用 模型会让你把底层思考透彻，业务逻辑就是写具体的业务逻辑，写完前面俩，最后一个自然而然就有了 |
 | 16 carytseng 2024 年 10 月 28 日 设计表，构建实体，填充实体，写 dao 层，写 service 并组合 dao ，写 controller 加验证判空之类，最后的最后优化下，要不要加锁，要不要写一些事务处理 |
 | 17 Kaiv2 2024 年 10 月 28 日 unit test -> controller || service -> dao |
 | 18 MYlyc 2024 年 10 月 28 日 现在是工作中是 2 ，现写 controller 写完 controller 发测试，前端可以照着 swagger 写 |
 | 19 devilweime 2024 年 10 月 28 日 dao 层，顺便确认下表设计有没有问题 |
 | 20 itechify PRO 先表设计，再 controller 定义接口，写好 service 看看需要 repository 哪些接口再写 dao |
 | 21 spritecn 2024 年 10 月 30 日 表设计 ->mapper(一般是空的) -> serviceImpl -> serviceInterface ->controllerInterface - controllerImpl ->拉起来测 我目前这么写,一般不会在 xml 或 mapper 里写 sql,所以我没有 DAO 层 |
 | 22 Aresxue 2024 年 11 月 5 日 Controller -> Mapper -> Service ，外部定义越早越好，对接的前端和其它三方可以直接查看 Controller 申成的接口文档，Mapper 其实主要指的是底层模型，这块是需要和老板/产品达成一致的，Service 指的是内部服务一般来说调整更自由，不管是改名字还是职责还是拆分都好说一些。 |
Select Language