问题背景：
??经过在学校的努力学习，2021届菜鸟毕业喽。终于踏上了接受社会毒打的历程，毕业后入职第一家公司，欢天喜地的打开项目准备写下毕业后的第一套增删改查，然后emmmmmmm
??公司的项目中，并没有在学校写项目时经常使用的实体类，而是统一采用List<Map<String,Object>>这种形式来传递参数，而且也没有使用mybatis，这让我一个刚进入代码界的初级开发显得有点手足无措。好在公司技术大佬给力，对新人也关注到位，给予了充分的时间学习并使用这种开发方式。
随着增删改查的日益熟练，也引发了我对这种开发方式的深思：
Java项目中，到底要不要用实体类，用的好处是什么？
??首先想一下，我们为什么要用实体类？
??我想了想，似乎当初在学校学的就是这样，老师规定：一个实体类对应一个表，方便接收参数，参数检验也方便。规范如此，我也就学到了这个。现在想想，当初竟然没有反问老师一句：为什么把这种开发方式当作规范。
??直到现在，我去问别人，为什么把建实体类当作规范，不写实体类就是不规范的写法，多数人给我的回答基本上都是：
??“因为……因为……我的老师就是这么教我的。
??“那为什么你老师认为这样做是规范？”
??“因为……因为……是我老师的老师这样教他的。”
??后来，通过各种途径学习，我了解到，写实体类其实是为面向对象这个思想服务的，大型项目中，领域建模是必须的，一系列实体构成对一个领域模型的描述和实现,，建模的最直接体现就是实体类，领域和数据库表不一定一一对应，它是对现实生活中的业务逻辑的翻译，你能很好的建模，你的项目可扩展性和维护性就越好，也就是所谓的面向对象编程。
??实体类就是一个拥有Set和Get方法的类。实体类通常总是和数据库之类的(所谓持久层数据)联系在一起。这种联系是借由框架(如Hibernate、mybatis)来建立的。
??实体类的定义：
??实体类主要是作为数据管理和业务逻辑处理层面上存在的类别； 它们主要在分析阶段区分 实体类的主要职责是存储和管理系统内部的信息，它也可以有行为，甚至很复杂的行为，但这些行为必须与它所代表的实体对象密切相关。
这段话看起来不太好懂，应该结合实体类的作用来看：
实体类的作用(需要面向对象的一点很基本的知识)：
实体类就是一个载体。
现在的设计差不多都是一张表就等于业务里面的一个类。一条记录(一般一行数据)是一个对象，一行中的一列就是这个对象的一个属性。
所以我们在操作某个表时(比如更改这个表的信息)，我们就可以在前台定义一个这样的对象，然后将其对应的属性赋值，然后传到后台。
这样后台就可以拿到这个对象的所有值了——不用一个一个属性当参数传过来，只要传一个这个类的对象就好了，也就是说只要一个参数就好了。好处不言而喻。
而这种前台对象到后台数据库的联系，我们是借由框架、配置文件来配置实现的，很方便快捷。并不需要自己手动编程实现。
简而言之，(大多数情况下)实体类就是数据库在Java代码中对应的东东。
??有了实体类，可以更方便的控制属性的读写（有只读 只写 和 读写）并且可以控制写的值是否合法（在set的时候进行判断赋值）以达到对数据操作的有效及安全，其次是为了让你的程序更方便的调用及操作（你可以将类实例后存在集合内）。
??通过以上的讨论，大致可以总结出用实体类的好处：
1. 参数清晰
2. 校验方便
3. 遵从面向对象思想
再多的暂时还没总结出来
??那如果没了实体类，也不用现在流行的mybatis框架，使用List<Map<String,Object>>这种方式传参呢？
??在学校时一直用java，实体类必写，即使是很小的一个宿舍管理系统也要强行封装一层，用实体类CRUD。现在在公司里，越来越感觉到不用的好处。
??首先直接明了的就是，代码写起来更加迅速且简洁了，开发效率真的奇高！
?? java中普遍使用的controller->service->dao->entity的分层方式, 也就是贫血模型
贫血模型，就是一个对象里只有属性，如java中的pojo，不包含业务代码
??贫血模型很貌似很经典, 但是写起来很啰嗦, 如果结合mybatis之类的, 多加几个mapper层, 实现就变得很复杂. 同时业务逻辑多起来后, 代码会爆炸.
??公司的这种无实体类，也没mapper层，自己封装了一套sql工具类的方式，将代码极大程度的简化了，我一直认同：大部分情况下，代码越少，越容易维护。我把你原来一二十行，分散到五六个类中的代码，简化到了两行代码搞定，就是这两行代码写的再复杂，读懂它能有多难？总比你原来五六个类来回跳容易多了吧？况且，这两行代码也根本就不复杂，反观你那一二十行代码，各种取值转换，各种循环嵌套。至于拿规范说事的人，一般都是菜鸡，不信你问他一句，为什么写实体类就是规范？不写实体类就不是规范？他大概率回答不上来。
??另外呢，我公司的业务比较复杂，需求经常来回转变，一个需求可能过个几天你都不认识它，不停的变需求意味着你要不停的改变代码，你就得不停的改变Map，接收Map的类也要不停的变，因为你map的key在不停的变，这时候如果你采用的实体类的方式，代码反而不好维护，还不如用List<Map<String,Object>>动态的获取参数来的方便。
??不过，对于开发人员是简便了，但从整个软件的参与人员来说，像客户（或有些BA、产品经理）这些不懂map list这类计算机概念的，沟通起来及其不顺畅。
??总的来说，经过两种开发方式的深度体验后，不适用实体类的方式在我看来有以下几个好处：
1. 开发方便
2. 代码简洁
3. 约束少，好扩展
4. 容易维护
??不过不用实体类也就要求了开发人员需要对表结构非常熟悉，对业务对象非常熟悉，由于Map里面，key是当变量名来用的，记得有次key敲错了，找半天，浪费了大量的时间。所以，使用这种方式也就要求了开发人员要对业务非常熟悉，熟悉业务也能更加方便的理清思路嘛。程序员不是机器，有现实可行的逻辑，才能写出流畅错误少的代码，模型与业务概念一一对应，理解起来快，写起来也快。
??另外，一个大型项目中这两种方式多多少少都会有，没有孰好孰坏，各有各的适用范围。
??用与不用，也是需要根据项目实际情况来决定，没有所谓的规范，走的人多了，便有了路，树之所以为树，是因为人叫它树，我们只是在尽可能统一树的概念而已。
??最后，送给大家一句在思考这个问题过程中看到的话：软件的生命周期不只是开发。
|