做 Java 服务器端 VO 属性越来越多怎么办

[burgleaf]

做 APP 开发的服务器端，有一个 DTO 和 VO，给 APP 提供的 API 输出和管理后台的参数输入输出全都是一个 VO。这样导致项目迭代了半年后 VO 越来越大，返回给 APP 的 API 其实不需要这么多的属性。 请问各位遇到这样的问题怎么解决？是拆开一个 requestVO 和 responseVO 好还是再加一个 BO 好？有没有更好的方案？

[jamesxu]

前期为了简单都共用一个 DTO，后期业务逻辑的增长也导致 DTO 里的字段增加，最好的做法就是拆出来，分成多个，接口只返回自己需要的 DTO，这样接口调用者也更清晰，只是后端稍微麻烦点，要加上 Entity 到各种 DTO 的转换
这里有例子，可以参考一下： https://mp.weixin.qq.com/s/DycPiC-aE31vX-e8YYdkEA

[Aidenboss]

为啥看起来是 GraphQL 的使用场景。https://graphql.org/

[tairan2006]

拆开啊，用新的 API 分担一部分工作

[night98]

我都是一个接口对应一个 vo，至于 entity 到 vo 的转换，参数名一致，beanutils.copyproperties 就搞定了。

[mmdsun]

jsonview 了解一下 json 视图

[ljzxloaf]

本人也是 APP 服务端开发，这个问题挺普遍，我是这么解决的，仅供参考。
首先我有一个 BO 类，代理所有相关业务的字段，我不知道你有没有 BO 类，因为我这边是调用其他服务的 RPC 接口，然后将他们数据过滤，聚合什么的，反正就是一些业务逻辑吧，其他服务都是“原子”服务，不处理业务需求的。但是正如你所说的，随着项目发展，这个 BO 的字段会越来越多，我不能在每个请求都去请求所有这些字段，这样既浪费我的计算资源，也会给依赖服务增加负担。然后我就参照 fastjson 那样的，增加了一个 Feature 枚举，将前端的不同的展示模式，比如有的是列表，有的是详情或者卡片什么的，每个展示模式下面需要调用的服务不同。这样在请求后端服务组装结果的时候，我可以根据 Feature 里面的服务集合去有选择性地调用，只需要在调用这个方法传入一个 Feature 即可。
这个过程完事之后，等于你已经将这次前段需求的字段全部拿到手了，后面你是根据不同的 VIEW 设置不同的 VO 还是只用一个 VO 都可以，只需将 BO 传给它们的构造方法转换一下就可以了。如果只用一个 VO 的话注意基本类型的字段尽量使用包装类，这样在序列化的时候如果这些字段没有填充的话不会序列化，减少一些网络开销。还有枚举我一般直接序列化成枚举名，可读性比较高，序列化反序列都很方便。至于 RequestVO 我是继承 ResponseVO 的，因为一些 From，To 什么的字段放在 ResponseV 里很奇怪。