1: dao层不应该有太多业务逻辑,比如,一个方法就只保存一个数据库表操作. 对比了一下 JourneyDao 太多的业务处理了
2: 面向对象尽量还是多用对象具体化,少使用hashmap,现在暂时分为3层对象
1:vo 专门负责 request对象
2: model: 将接收进来的vo对象转化 ,比如传进来的是一些
3:po 只跟数据库有关系,且字段都跟数据要一致 ,没有冗余
这么做的原因是:1:有时候我们查询的一些数据,到前台的显示都完全不太一致, 所以就有了model和vo之间的转换
2: model和po之间的转换,是为了不污染数据操作层,比如dao写业务逻辑.所以我们的model可以冗余各种list对象 ,比如journey冗余List<Address>
3:尽量每个接口都使用泛型,第一眼就能看出这个接口返回了什么对象,然后也可以点击进去看.而不是map对象或者Object对象.比如行程接口,我必须返回
Journey对象,其他的附属对象List<Address>嵌套在对象里面,而不是使用List嵌套hashmap.这个就完全没有可读性而言了.对于开发来调用者来说.
就必须一个一个方法查找,找到对应的key,而且不能写错.
4:对于一个对象的新增.或者修改方法,无论多少个字段,在dao层只写一个方法, 只是根据对象字段是不是为空逐个去更新.而不是修改一个字段,新增一条sql,这样写的话,就会很难维护了.
5:对于数据库查询也是,如果单表查询,应该也是dao只写一个方法,只是传输不同的查询对象Critetai进来,建议最好也还是不要用hashmap,
所以对于单表操作,在业务不是很复杂的情况下,大多数情况下会是单表的增删该查. 所以如果使用4和5的话,将会节约很多时间,和减少很多不必要的bug,而且也好维护
6:代码中尽量减少,if XX==null的判断 和 list.size的判断,所以我们在查询的时候 就返回一个size为0的对象 .(因为NULL本来就是程序设计上的一个缺陷)
7:业务代码中尽量不要写死代码,最典型的就是类型,type=1 type=2 ,都应该改成枚举 .现在journey里面有很多这样的情况,后续改进
8:分页组件也需要好好优化一下, 现在的分页,必须要自己手动写2条sql,一条查询信息,一条查总数, 按照道理应该只写一条就可以了,另外一条,只不过是吧* 该成count.
9:对于代码中sql查询出来的list,需要做model和po转换的,最好不要写在service里面,一来显得 代码杂乱,二来不好公用 .
MVC的职责应该更加明确，各层的耦合度就越低，越低的话，可读性高（都是同样的一个套路来的），可维护性强（controller想换springmvc就Springmvc，想struts2就struts2，service想换dubbo就dubbo，想换probuf就换probuf，dao想换mybatis就换mybatis，想换hibernate就hibernate）
1:dao层只专注做某个数据库的增删改查 ,所以dao层,只传入跟数据库有关联的po对象.这样dao层的就不会显得臃肿了,简单的做一件事情,出错的话,也就好排查问题,而且对于扩展就更加方便了,因为没有跟业务代码耦合
所以dao只专注数据库的增删改查: 1:单表操作只传入PO对象，对应一条sql语句
2：对于多表查询，也只是传入一个sql需要执行的参数对象。
2:service也只尽量写跟业务逻辑有关联的一些操作,对于类似 po和model这类的转换,虽然也是service应该做的,但是我们还是把它抽出来一个util,这样service也不会显得臃肿,而且util可以复用.
所以service只做几件事情：1 接收controller的参数，进行一些参数合法验证，尽早抛出异常
2：执行一些业务逻辑之后，将controller传过来的对象，转换成为dao层需要操作的po对象
3：调用dao执行
3:对于controller层,我们也不应该耦合一些业务流程,它只负责把数据拿出去显示,所以,我们接收到service返回的model对象.我们唯一要做的就是,可能前端显示的跟我们返回的不一样,比如性别service返回0 或者1
而前端要显示男和女,这样转换就需要我们去做了,
所以controller只做几件事情: 1:接收前端传过来的参数,进行一些字段的合法性验证
2: 操作权限等等的一些验证,比如登陆权限 ,频率控制等等
3:接收service返回的对象,重新组装试图数据返回.
4: