随着增删改查的日益熟练，也引发了我对这种开发方式的深思：

Java项目中，到底要不要用实体类，用的好处是什么？

  首先想一下，我们为什么要用实体类？
  我想了想，似乎当初在学校学的就是这样，老师规定：一个实体类对应一个表，方便接收参数，参数检验也方便。规范如此，我也就学到了这个。现在想想，当初竟然没有反问老师一句：为什么把这种开发方式当作规范。
  直到现在，我去问别人，为什么把建实体类当作规范，不写实体类就是不规范的写法，多数人给我的回答基本上都是：
  “因为……因为……我的老师就是这么教我的。
  “那为什么你老师认为这样做是规范？”
  “因为……因为……是我老师的老师这样教他的。”
  后来，通过各种途径学习，我了解到，写实体类其实是为面向对象这个思想服务的，大型项目中，领域建模是必须的，一系列实体构成对一个领域模型的描述和实现,，建模的最直接体现就是实体类，领域和数据库表不一定一一对应，它是对现实生活中的业务逻辑的翻译，你能很好的建模，你的项目可扩展性和维护性就越好，也就是所谓的面向对象编程。

  有了实体类，可以更方便的控制属性的读写（有只读 只写 和 读写）并且可以控制写的值是否合法（在set的时候进行判断赋值）以达到对数据操作的有效及安全，其次是为了让你的程序更方便的调用及操作（你可以将类实例后存在集合内）。
  通过以上的讨论，大致可以总结出用实体类的好处：
1. 参数清晰
2. 校验方便
3. 遵从面向对象思想

再多的暂时还没总结出来

  那如果没了实体类，也不用现在流行的mybatis框架，使用List<Map<String,Object>>这种方式传参呢？
  在学校时一直用java，实体类必写，即使是很小的一个宿舍管理系统也要强行封装一层，用实体类CRUD。现在在公司里，越来越感觉到不用的好处。
  首先直接明了的就是，代码写起来更加迅速且简洁了，开发效率真的奇高！
   java中普遍使用的controller->service->dao->entity的分层方式, 也就是贫血模型

  贫血模型很貌似很经典, 但是写起来很啰嗦, 如果结合mybatis之类的, 多加几个mapper层, 实现就变得很复杂. 同时业务逻辑多起来后, 代码会爆炸.
  公司的这种无实体类，也没mapper层，自己封装了一套sql工具类的方式，将代码极大程度的简化了，我一直认同：大部分情况下，代码越少，越容易维护。我把你原来一二十行，分散到五六个类中的代码，简化到了两行代码搞定，就是这两行代码写的再复杂，读懂它能有多难？总比你原来五六个类来回跳容易多了吧？况且，这两行代码也根本就不复杂，反观你那一二十行代码，各种取值转换，各种循环嵌套。至于拿规范说事的人，一般都是菜鸡，不信你问他一句，为什么写实体类就是规范？不写实体类就不是规范？他大概率回答不上来。
  另外呢，我公司的业务比较复杂，需求经常来回转变，一张表的结构可能过个几天你都不认识它，不停的变需求意味着你要不停的改变代码，你就得不停的改变Map，接收Map的类也要不停的变，因为你map的key在不停的变，这时候如果你采用的实体类的方式，代码反而不好维护，还不如用List<Map<String,Object>>动态的获取参数来的方便。
  不过，对于开发人员是简便了，但从整个软件的参与人员来说，像客户（或有些BA、产品经理）这些不懂map list这类计算机概念的，沟通起来及其不顺畅。
  总的来说，经过两种开发方式的深度体验后，不适用实体类的方式在我看来有以下几个好处：
1. 开发方便
2. 代码简洁
3. 约束少，好扩展
4. 容易维护

  不过不用实体类也就要求了开发人员需要对表结构非常熟悉，对业务对象非常熟悉，由于Map里面，key是当变量名来用的，记得有次key敲错了，找半天，浪费了大量的时间。所以，使用这种方式也就要求了开发人员要对业务非常熟悉，熟悉业务也能更加方便的理清思路嘛。程序员不是机器，有现实可行的逻辑，才能写出流畅错误少的代码，模型与业务概念一一对应，理解起来快，写起来也快。
  另外，一个大型项目中这两种方式多多少少都会有，没有孰好孰坏，各有各的适用范围。
  用与不用，也是需要根据项目实际情况来决定，没有所谓的规范，走的人多了，便有了路，树之所以为树，是因为人叫它树，我们只是在尽可能统一树的概念而已。
  最后，送给大家一句在思考这个问题过程中看到的话：软件的生命周期不只是开发。