向师傅们请教 pojo 类设计的规则。什么时候需要设计一个 pojo 接受参数，什么时候用 map/list 等
mart1nN · 2019-08-21 10:41:55 +08:00 · 3963 次点击这是一个创建于 1955 天前的主题，其中的信息可能已经有所发展或是发生改变。
我目前的理解是每张表需要写一个 pojo 类，然后涉及多张表且参数不固定的用 map
但是实际上大多数情况下的业务都需要查询 2 张表以上
请问师傅们是怎么处理的
 |
1
taogen 2019-08-21 11:07:17 +08:00 via Android
实体类之间一般是一对一、多对多之类的关系，一般用 object 或 list 关联。不固定操作和实体类操作分开处理。
|
 |
2
xiaoyaojc 2019-08-21 11:24:14 +08:00
最好不要用 map 做方法入参和返回参数，后续很难维护。我司查表返回的，如果单表就是 DO，联表就是 PO
|
 |
3
liuhuansir 2019-08-21 11:26:06 +08:00
原则上不是不允许用 map 做入参和出参么？只是 pojo 类数量会爆炸
|
 |
4
glaucus 2019-08-21 11:27:24 +08:00
我目前的本方法是每个表有两个 pojo 类，一个字段一对一，一个包含各种关联字段，一般新增、修改、删除时用第一个，查询时用第二个
|
|
5
glaucus 2019-08-21 11:28:37 +08:00
@glaucus #4 本 --> 笨 ，再补一下，楼主的这种问题在 Kotlin 下更突出，因为 Kotlin 还默认要求字段不能为 null，蹲一个优雅的解决方案
|
 |
6
mart1nN OP @liuhuansir 是的，目前来说我还是每次查询都新建一个 pojo 类，一方面也是担心 map 难以维护，另一方面从面向对象的原则来说也应该用 pojo 类，但是 pojo 类的剧增还是让我很不舒服
|
 |
7
caoqiang250 2019-08-21 17:28:31 +08:00
全是 map，list<map>,没写过 pojo 类的路过，写 pojo 太累了。。。。。。
|
 |
8
chendy 2019-08-21 17:32:21 +08:00
楼上全是 map 的老哥是不是公司只有一个人？…
|
 |
9
yyConstantine 2019-08-21 17:38:27 +08:00
@chendy 我表示，我们这里的技术 leader 推崇 map，嫌用 pojo 太冗余，我只能自己默默写 pojo。。
|
|
10
chendy 2019-08-21 17:39:30 +08:00
除非真的需要 map，否则不要用 map，毕竟不用等别人接手，过段时间自己看都想不起来 map 里传的啥
pojo 也是跟着分层走的，DataObject 对应数据库表，BussinessObject 对应业务，ViewObject 对应展示，如果用了 ORM 的话 DataObject 有可能不需要，简单场景可能 DataObject 完全够用 个人经验是，pojo 太多太碎通常是对业务建模不够，导致数据模型不能很好表达业务模型，进而导致难以复用 |
|
11
caoqiang250 2019-08-21 19:04:31 +08:00
使用 pojo 在后期维护的时候也会出现很麻烦的情况啊，例如某个表加减一些字段，某个接口需要返回的参数发生变化，这种时候不仅需要改 pojo,还要该 sql,而使用 map 直接该 sql 就好，我觉得很省事啊。望后面大佬轻喷。。。。。。（我这边一般会把每个接口接收哪些数据，返回哪些数据整理成 xls 的，所以一般情况下也不太会出现不知道传的啥的情况）
|
 |
12
Takamine 2019-08-21 20:21:01 +08:00 via Android  1
po 对应表结构，多表关系业务层封装处理拼装 vo，不用完全按领域模型来。
用 map 的话，感觉接收的字段都显式获取不太优雅，也不利于维护。 |
Select Language