DTO到底是个啥子玩意儿

先说说DTO全名叫Data Transfer Object，顾名思义，就是专门搬数据的。

在项目里它常常被当成“中间人”，把数据库实体塞进去，再往前端吐。

听起来挺好，是吧？可是一不小心，就会变成“类的墓地”。

哈哈，我跟你讲，这事儿我也踩了坑，后来才明白，所谓的“过度使用”，其实是我们太爱造轮子了。

为啥大家dou爱搞一大堆DTO

第一，业务需求千变万化，一点点改动就想新建个DTO。

第二，团队里有人觉得不暴露Entitygeng安全，于是把Entity锁进后门。

第三，有的框架要求Response必须是DTO，这就geng容易把DTO堆成山。

你kan，这几个原因加一起，就是“类炸弹”。

过度使用的危害，你懂的

类文件多到找不到北，IDE卡顿得像老爷车。

维护成本飙升，每改动一次业务，dou要翻遍所有相关DTO。

新人上手难度大，一眼望过去，全是相似又冗余的代码。

Zui怕的是真正需要优化性Neng的时候，你发现自己Yi经在写层层包装的“洋葱”。

怎么遏制这个乱象？咱来说几招

1️⃣ 用Entity直接返回

Ru果业务逻辑简单，字段没有敏感信息，其实Ke以直接把Entity交给Controller。

当然要确保没有泄漏密码、内部状态这些东西。

说实话，这招省事儿，而且省掉了一堆冗余类。

2️⃣ 合理划分层级，用Record代替传统DTO

Java 14以后有record，它天生不可变，还Neng自动生成构造器和getter。

一个record一句话就Neng搞定，大幅削减样板代码。

public record UserInfo {}

3️⃣ 把相似的DTO合并成一个通用对象

比如创建、geng新、查询这几种请求，大多数字段dou是一样的，Ke以用同一个Request对象，只在校验组上区分。

这样一来就不会出现UserCreateDTO、UserUpdateDTO、UserQueryDTO这种“一屋子兄弟”。

4️⃣ 用注解或视图控制返回字段，而不是每次dou建新类

@JsonView配合不同视图，就Neng在同一个类里灵活控制哪些属性对外可见。

public class UserVO {
    @JsonView
    private Long id;
    @JsonView
    private String email;
}

5️⃣ 把业务聚合到少数几个核心DTO里

CQRS思路里我们只需要两个方向：写入命令和读取视图。

CQRS让我们自然地把写请求和读返回分离，从而避免无谓的细粒度类爆炸。

组织结构也hen重要，别让包裹得像迷宫

把所有Dtodou扔进一个dto包，kan起来整洁，其实找起来像捉迷藏。

Simplify一下：按业务域划分子包，比如user/request、user/response，这样一眼就知道该去哪儿找。

"为什么百度不收录"——顺便聊聊SEO小插曲

说到网站流量，有朋友总问："为什么百度不收录"?

其实原因hen简单，内容重复率高、页面加载慢或者缺少关键字dou是罪魁祸首。

#重复内容： Ru果你的页面几乎和别的页面一模一样，搜索引擎会认为没价值，自然不收录。

#技术问题： 页面渲染用了太多JS而没有SSR，爬虫抓不到真实内容，也会被忽略。

#结构混乱： 标题层级错位，meta描述为空，dou让搜索引擎抓瞎眼。

Crap，不对不对，我刚才跑题了！回到正题——控制DTO数量本身也Neng间接提升SEO，因为项目结构清晰、构建速度快，部署后页面响应geng迅速，自然有利于搜索引擎友好度。

end of story——几句温馨提示

别把每个细节dou装进独立的DTO，那只会让代码库膨胀成“大肥肉”。

AOP或者拦截器Ke以帮你统一处理日志、权限之类的横切关注点，而不是靠一堆专用Dto来实现。

B站上有不少老哥分享“记录式 DTO”技巧，你Ke以去kankan，我也是从那学来的。哈哈~

Coding时记得问自己：“真的需要这个类吗？”Ru果答案是“不确定”，那就先不要写。

P.S. Ru果你Yi经深陷 DTO 海洋，不妨抽时间Zuo一次“类清理”，把冗余删掉，让项目呼吸一下新鲜空气。

- 老友敬上 -

---