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

实体类之间一般是一对一、多对多之类的关系，一般用 object 或 list 关联。不固定操作和实体类操作分开处理。

最好不要用 map 做方法入参和返回参数，后续很难维护。我司查表返回的，如果单表就是 DO，联表就是 PO

原则上不是不允许用 map 做入参和出参么？只是 pojo 类数量会爆炸

我目前的本方法是每个表有两个 pojo 类，一个字段一对一，一个包含各种关联字段，一般新增、修改、删除时用第一个，查询时用第二个

@glaucus #4 本 --> 笨 ，再补一下，楼主的这种问题在 Kotlin 下更突出，因为 Kotlin 还默认要求字段不能为 null，蹲一个优雅的解决方案

@liuhuansir 是的，目前来说我还是每次查询都新建一个 pojo 类，一方面也是担心 map 难以维护，另一方面从面向对象的原则来说也应该用 pojo 类，但是 pojo 类的剧增还是让我很不舒服

全是 map，list<map>,没写过 pojo 类的路过，写 pojo 太累了。。。。。。

楼上全是 map 的老哥是不是公司只有一个人？…

@chendy 我表示，我们这里的技术 leader 推崇 map，嫌用 pojo 太冗余，我只能自己默默写 pojo。。

除非真的需要 map，否则不要用 map，毕竟不用等别人接手，过段时间自己看都想不起来 map 里传的啥
pojo 也是跟着分层走的，DataObject 对应数据库表，BussinessObject 对应业务，ViewObject 对应展示，如果用了 ORM 的话 DataObject 有可能不需要，简单场景可能 DataObject 完全够用
个人经验是，pojo 太多太碎通常是对业务建模不够，导致数据模型不能很好表达业务模型，进而导致难以复用

使用 pojo 在后期维护的时候也会出现很麻烦的情况啊，例如某个表加减一些字段，某个接口需要返回的参数发生变化，这种时候不仅需要改 pojo,还要该 sql,而使用 map 直接该 sql 就好，我觉得很省事啊。望后面大佬轻喷。。。。。。（我这边一般会把每个接口接收哪些数据，返回哪些数据整理成 xls 的，所以一般情况下也不太会出现不知道传的啥的情况）

po 对应表结构，多表关系业务层封装处理拼装 vo，不用完全按领域模型来。
用 map 的话，感觉接收的字段都显式获取不太优雅，也不利于维护。