[排错] VO对象和POJO对象的关系

　　这或许是一个很蠢的笔记吧......

　　这次项目中, 作为一个新人, 没少被这两个概念虐得死去活来的, 现在特别做一次记录, 关于它们二者之间在项目中的应用.

　　在这里呢, 就不再赘述 VO(view object) 对象 和 POJO 是什么了, 这两个网上是有很多介绍的了, 好的, 话不多说, 直奔主题.

　　背景: 从数据库中查询出某一天中24个小时的数据, 也就是 日期的查询参数是 yyyy-MM-dd ,可以查询到 [0--23] 24个小时的数据 

一开始博主的想法是, 在数据中, 将 yyyy-MM-dd HH-mm-ss 拆分成 yyyy-MM-dd 和 HH-mm-ss 两个部分, 但是这会造成一个问题, 因为项目需要, 日期是作为主键存在的, 这样的话会出现问题,

那么就只能换一种方法来自解决问题, 那就是时间的格式不变的情况下, 才采用 MySQL 数据库自带的 DATE_FORMAT 函数,

　　

　　假设有这样的三条数据:[    id  yyyy-MM-dd HH-mm-ss  info   ]

　　　　　　　　　　　　 [    id  yyyy-MM-dd HH-mm-ss  info   ]

　　　　　　　　　　　　 [    id  yyyy-MM-dd HH-mm-ss  info   ]

　　然后我们在  mapper.xml  中这样查询  SELECT * FROM tbaleName WHERE  DATE_FORMAT(record_date) = #{date}

　　对应的数据映射接口中  mapper.java  这样设计接口   List<POJO> query (PojoKey pojoKey);   因为我们是一次性查询出3条数据, 或者是 24条数据

　　然后就开始精彩的部分了, 因为我们要直接在页面上展示的格式为 :   

　　POJO 是作为对应数据源对象而存在的,  博主之前一直以为数据从数据库中查询出来以后, 是保存到 POJO 里面的, 但是, POJO 里的属性只是对应着数据库的数据字段的别名[这里, 还是很可疑, 不是很确定],

所有数据库表中有哪些字段, POJO 里就要有哪些数据类型对应, 且命名一致的属性, 并且添加对应的 get/set 方法, 但是仅仅是这样是不够的, 看看表里的数据和页面上所需要展示的数据是不一样的, 所以, 我们需要在 VO 中做一些操作.

　　但是在操作之前, 我们需要先有一个  service  层的类   Service.java  别忘了加上 @Service, 在 service 中添加一个方法, 用于向 controller 层返回数据, 返回值的格式根据项目需求自己定义 ( 这里我们定义方法的签名为  public  List(VO) getInfo (Type param), 然后调用数据映射接口的 bean , 遍历  Liset<POJO> 中的每一条数据, 由于 POJO 作为数据源的对象, 所以在 service 层可以使用   

　　　　List<POJO> getMapperInfo = mapperBean.query(param); // 调用执行SQL语句, 获取DB中的数据, 

　　　　List<VO> viewInfoList = new ArrayList<>(0); //创建一个 VO 类型的集合, 用于保存多条计算加工后的 POJO 对象的数据

　　　　 ( 其中 changeDataFunction 就是 VO 对象中的静态方法, 这里有一个疑问就是, 如果去掉修饰 changeDataFunction 的 static 关键字, 那么方法所  set  的数据, 将 无法修改  VO 类中的属性值? 为什么?)

　　这样, 再 return viewInfoList; 就大功告成了, controller 层的代码几乎可以忽略.

　　大致思路已经讲完, 那么相信对 POJO 和 VO 对象的用法和区别已经有了已经初步的认识了吧.

　　简单来说,   POJO 对象就是对应着数据表的字段类, 由于在查询的时候我们要使用到查询参数 ,  所以对于主键字段, 博主还是建议单独抽出来建一个 PojoKey 对象要友好一些, 毕竟对于多主键同时查询的时候, 也会方便代码的维护. 

　　而 VO 对象, 就是为页面数据服务的对象, 它存在的意义就是帮助 controller 层将从 DataSource 里拿到数据经过 POJO 的整理后 进一步的 按照页面展示的数据需求对数据进行加工, 最后经由 service 返回给 controller 层, 最后填充到页面表格中.

　　所以说 POJO 是面对 mapper 映射层 和 service 服务层的, 而 VO 是面对 service 服务层和 controller 控制层, 博主之前犯的最大的一个错误就是将 VO 和 POJO 的位置和定位搞混, 一直想着怎么直接在 POJO 中操作完数据然后传入 VO 中, 最后返回给 controller, 这其实就是因为博主将目光只停留在了数据层, 而没有通过需求从整体上来看代码.

　　所以说在一开始接到一个项目的时候, 正确的操作流程应该是: 

　　[1] 确定需求, 理解需求, 保证开发和QA的思路是大致在一条线上的, 也要保证自己真的明白了需求的目的;

　　[2] 确定技术选型, 设计数据源(这一步其实挺关键), 在理解需求的前提下降数据库表设计完成(包括数据类型, 还有对 增删改查 操作时的友好度);

　　[3] 简单的画一个 UML流程图, 再配上简单的几行伪码, 大致考虑一下整个需求的运行情况, 要可以预想到哪里容易出BUG, 哪里可以继续优化, 哪里可以应对更多的需求变化,,等等;

　 [4] 这里就可以开始一脸自信的写BUG了(滑稽), 

　[5]  工作日常    哈哈,其实前期的准备和设计是非常重要的, 就在博主做的这个需求中, 一个星期的时间, 其实真正花在 coding 上的时间并不多, 而这宝贵的时间都浪费在由于前期设计不足而导致的种种纠结

嘤嘤嘤,,,,,其实我有想过贴代码啦,  不过,, 我认为编程中最重要的思路, 代码,其实真的不难的好伐, 只要思路确定了, 剩下的就只是变态的性能优化了, 这一点只能靠自己的努力或者说经验了, 第一篇博文,,,,哇,满满 的成就感

如果有小伙伴看到这里,,非常感谢,,也欢迎各位大佬提出建议和意见   ~~~~