关于 SSM 框架下实体类的一些疑问

滥用 map 不如用动态语言写…公司的旧项目里很多方法返回值是 JsonObject，IDE 的静态检查全废了。新项目里复杂类型的参数和返回值都要定义类

我司历史遗留项目也有这种情况：所有的方法的参数都是 Map 或 Map<String, Object>。

这种方式编码的问题在于：
1 ）程序不运行起来不知道 Map 中有什么内容，即哪些 Key-->Value 对。
2 ）获取 value 值后需要强制类型转换，无法发挥 Java 静态类型的编程语言的优势。
3 ）更多情况下 Map 不仅仅用来传参，还会用来保存返回值。比如一个方法调用链 ：funcA(Map) --> funcB(Map) -- funcC(Map) ，这里面的函数可能存在会出现这种情况，funcB 中又修改了 key = foo 对应的 value 值，然后 funcC 中添加 key = bar 对应的 value 值，然后 funcA 中又读取了 foo 和 bar。

一般都是有实体类的。感觉用 map 不太方便知道里面有什么字段，实体类可以直接调用 getter 方法就可以了。

用实体类，第一清晰、明了，第二用 `map.get` 的时候使用字符串填充容易出错。

另外，用实体类可以很好的利用面向对象特性，抽象，封装，继承，多态。

@Xbluer 确实是这样的，看他们写的接口不看借口文档根本看不懂到底接收哪些参数，所以我一般都会在接口注释中写上接受的参数列表。

只是最近在自己写个东西在纠结还要不要按照公司那种，现在我觉得我应该用实体类封装一下来弄。

大佬有没有什么好的开源项目推荐一下呀

多写几个实体类死不了人，全用 Map 迟早掉坑里。

@taogen 但我现在用 map 有点上瘾，所以准备跳出来看看

不如用动态语言了

用实体类相当于在给接口写文档。而且调用者不看文档就知道类里有哪些变量

java 这种强类型语言，参数用 map 很容易增加心智负担和掉坑。 比如一次 count 字段，你 map.get 时，得思考这里面是一个 Integer 呢还是 Long 呢，结果一顿操作后发现传了个 string 型的数字

可以看下这个项目 https://gitee.com/lcg0124/bootdo

@az422 还真是这样，前些天写了两个报表，各种强制类型转换

ma

学习了，除了上面说到的点以外，还有性能上的差异我觉得也需要考虑上。

滥用 map 导致现在的契约测试和前后端分离的类型校验完蛋了，那大部分接口可用性基本靠人肉覆盖了？

什么是实体类？

接受一般都是 xxxVO，返回一般都是封装好的 ServiceResponse<T>。

一直用实体类，不过被公司新来的安卓喷了，说太复杂看不懂，哈哈。

@yukiir 我们公司安卓都是把后台给的 json 转为实体类来用的

@yukiir 所以经常看到他们有一堆的内部类

现在 ts 这么火的原因就是类型严格有助于控制瞎几把整，并且提升了重构的安全性，都用 map 了那直接用弱类型的动态语言梭哈不是更爽，没到一定数量级，机器比人便宜多了。

都写实体类吧，用 lombok 写个实体类也花不了什么功夫。

就行