跳到主要内容

Java 项目里的 DAO、Service、Controller 命名最好早点统一

· 阅读需 3 分钟
一介布衣
一介布衣
全栈开发者

2016 年接手 Java 项目时，我遇到过一种很典型的混乱：同样是处理用户逻辑的类，有的叫 UserDao，有的叫 UserMapper，有的叫 UserServiceImpl，还有的直接叫 UserManager。项目还能跑，但只要需求稍微一变，大家就会先花时间猜“这个类到底管什么”。

我后来越来越觉得，DAO、Service、Controller 这些名字如果不早点统一，项目会在很长一段时间里持续付出沟通成本。

命名问题不是审美问题​

很多团队刚开始不在意命名，会觉得“能看懂就行”。
可工程项目不是只给当前作者看，还是给后来接手的人、联调的人、排障的人看。

当一个类名不能稳定表达职责时，连最基础的讨论都会变慢：

  • 数据库访问应该放哪一层
  • 事务边界应该由谁控制
  • 参数转换是 Controller 负责还是 Service 负责

你会发现，很多争论并不是技术难，而是词没有先约定好。

我后来给三层定下来的最小规则​

我不追求特别复杂的命名体系，只坚持几条够用的原则：

  • Controller 只负责接请求、转参数、回响应
  • Service 负责业务编排和事务边界
  • Dao 或 Mapper 负责数据存取，二选一，不混用

如果团队用 MyBatis，我更倾向统一叫 Mapper；如果是更传统的分层写法，就统一叫 Dao。关键不是选哪个词，而是项目内部不要同时存在两套话语。

命名一乱，最伤的不是代码，而是边界​

真正麻烦的不是类名不好看，而是边界会跟着糊掉。
比如一个叫 UserManager 的类，今天可能在查数据库，明天又开始发短信，后天还顺手做了权限判断。它的名字太宽，就等于默认鼓励它什么都接。

而一旦类名本身就带着职责约束，很多坏味道会更早暴露出来。
你不太容易理直气壮地把业务流程塞进 UserDao，也不太容易把 SQL 拼装塞进 UserController。

我通常怎么推这个规范​

我不会一上来就要求团队背一大堆文档，而是先从新代码开始：

  • 新增控制层统一叫 *Controller
  • 业务入口统一放在 *Service
  • 数据访问层固定一套后缀
  • 评审时只要发现跨层命名，立刻指出来

先把新增部分守住，再慢慢去整理旧代码，阻力会小很多。

一个够用的自查问题​

如果你现在打开一个 Java 类，光看类名还需要再翻实现才能知道它是不是负责业务、是不是负责 SQL、是不是负责 HTTP，那这个命名大概率就不够稳。

命名统一不会直接让项目更快，但它会让后续每一次改动都更便宜。2016 年以后我对这一点越来越笃定：分层体系先统一词，再统一代码，效果会好得多。