未分類
9 9 月 2020

当字段较多且经常需要新增字段时，用 JSON 代替 POJO 是否更加合适？

当字段较多且经常需要新增字段时，用 JSON 代替 POJO 是否更加合适？

資深大佬 : lauyukit 2

各位大佬们，小弟在重构一个项目，因为业务需要，一些 POJO 实体类有很多字段，而且随着时间和业务变化，会增加各种不同的字段，老代码里都是用 JSONObject 一把梭，我觉得这样很不好，一来没有辨识度，没法通过静态分析发现问题，二来很不优雅；可是定义 POJO 的话，又因为字段多变，可能需要成员变量里加一个 Map 来扩展，不然每新增一个字段就得通过继承或者定义新 POJO 来做了。不知道大佬们有没有更好的办法？
大佬有話說 (10)

  • 資深大佬 : hyperbin

    改成字段存数据库

  • 資深大佬 : freebird1994

    我们现在是这样的。因为是 2b 的业务，平台方有些字段传入会有差异，差异的字段都是放在 map 里

  • 資深大佬 : qwerthhusn

    有需要搜索，排序的字段得用单独的字段和单独的数据库列
    其他的，尤其是后台基本上连看都不看直接扔前台的，可以弄到 extend_params 里面，json 就行
    我是这么感觉

  • 資深大佬 : liuxey

    我更好奇字段这么多变，数据库怎么设计？ NoSQL ？ JSON 列？

  • 主 資深大佬 : lauyukit

    @qwerthhusn 那看来都是这么处理了

  • 主 資深大佬 : lauyukit

    @freebird1994 嗯嗯，我也是这么想的，公共的提取出来，差异化的放 map 里

  • 主 資深大佬 : lauyukit

    @liuxey 我目前想到的是 JSON 列，或者转 String

  • 資深大佬 : saulshao

    我之前的方法都是弄个保存列名的表。
    等到需要的列要大量查询的时候再把这个字段转到普通的表里面去。

  • 資深大佬 : srlp

    protobuffer

  • 資深大佬 : Nillouise

    用 map 存储说明你不会使用该字段进行逻辑处理，那么存在数据库的 json 字段应该是可以的。

    涉及逻辑处理你当然得用一个 field 存储（数据库中需不要单独字段另说），多定义一个 pojo 不是什么大问题，因为不同得的逻辑层需要不同样的 vo 是很正常的。