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

[qianyan]

今年刚毕业，一直有个关于我们公司开发框架的疑问

公司用的框架都是无实体类的，接收参数，返回数据都是用 map 封装，sql 传值也是 map。意思就是已经完全脱离了实体类，一直觉得怪怪的，问了两个同学他说他们不是这样的，我就想了解一下其他人是怎么写的，然后在 github 上找了两个前后端分离的 ssm 框架的开源项目，但感觉他们实体类也没什么用处，甚至一个项目中接收参数既有对象，也有普通类型，还有 map 看得我都不知道怎么的好了🤣🤣

想听听大佬们是怎么做的

或者有什么好的开源项目让我可以借鉴一下🐒🐒

[zjp]

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

[Xbluer]

我司历史遗留项目也有这种情况：所有的方法的参数都是 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。

[taogen]

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

[mamian]

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

[taogen]

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

[qianyan]

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

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

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

[xuanbg]

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

[qianyan]

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

[cheng6563]

不如用动态语言了

[aguesuka]

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

[az422]

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

[taogen]

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

[qianyan]

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

[aaahhh123]

ma

[leafShimple]

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

[luozic]

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

[hhhsuan]

什么是实体类？

[Takamine]

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

[yukiir]

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

[qianyan]

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