向师傅们请教 pojo 类设计的规则。什么时候需要设计一个 pojo 接受参数，什么时候用 map/list 等

我目前的理解是每张表需要写一个 pojo 类，然后涉及多张表且参数不固定的用 map

但是实际上大多数情况下的业务都需要查询 2 张表以上

请问师傅们是怎么处理的

答:实体类之间一般是一对一、多对多之类的关系，一般用 object 或 list 关联。不固定操作和实体类操作分开处理。
答:最好不要用 map 做方法入参和返回参数，后续很难维护。我司查表返回的，如果单表就是 DO，联表就是 PO
答:原则上不是不允许用 map 做入参和出参么？只是 pojo 类数量会爆炸
答:我目前的本方法是每个表有两个 pojo 类，一个字段一对一，一个包含各种关联字段，一般新增、修改、删除时用第一个，查询时用第二个
答:全是 map，list<map>,没写过 pojo 类的路过，写 pojo 太累了。。。。。。
答:楼上全是 map 的老哥是不是公司只有一个人？…
答:除非真的需要 map，否则不要用 map，毕竟不用等别人接手，过段时间自己看都想不起来 map 里传的啥
pojo 也是跟着分层走的，DataObject 对应数据库表，BussinessObject 对应业务，ViewObject 对应展示，如果用了 ORM 的话 DataObject 有可能不需要，简单场景可能 DataObject 完全够用
个人经验是，pojo 太多太碎通常是对业务建模不够，导致数据模型不能很好表达业务模型，进而导致难以复用
答:使用 pojo 在后期维护的时候也会出现很麻烦的情况啊，例如某个表加减一些字段，某个接口需要返回的参数发生变化，这种时候不仅需要改 pojo,还要该 sql,而使用 map 直接该 sql 就好，我觉得很省事啊。望后面大佬轻喷。。。。。。（我这边一般会把每个接口接收哪些数据，返回哪些数据整理成 xls 的，所以一般情况下也不太会出现不知道传的啥的情况）
答:po 对应表结构，多表关系业务层封装处理拼装 vo，不用完全按领域模型来。
用 map 的话，感觉接收的字段都显式获取不太优雅，也不利于维护。