文档章节

真正实践才能理解的 MVC职责

_江左梅郎_
 _江左梅郎_
发布于 2015/11/24 17:30
字数 1387
阅读 29
收藏 0

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:


© 著作权归作者所有

_江左梅郎_
粉丝 0
博文 6
码字总数 5420
作品 0
深圳
私信 提问
浅谈MVC/MVP/MVVM模式(MVC简单实现)

经过之前的在JavaScript中理解策略模式、在JavaScript中理解组合模式、浅谈MVC/MVP/MVVM模式(概述) 和 较早之前的进击的观察者模式等文章的铺垫,终于可以把这些理论的东西用于实践了。 废...

夜曉宸
02/07
0
0
用 Hasor 谈一谈MVC设计模式

MVC 是一个老生常谈的东西早已不是什么稀罕物件,不过在这里还是扒一扒到底都有多少种 MVC。 一、经典 MVC 先说最经典的 MVC,一个请求控制器的请求,负责读取数据,然后将数据派发到试图上。...

哈库纳
2016/09/29
184
0
MVP那些事儿 (3)……在Android中使用MVC(上)

为什么要先介绍MVC? 如果你要想更佳深刻的理解MVP,并在实际开发中灵活的应用,那么就要先了解它的低配版MVC,他俩只是一步之遥,先了解MVC再学习MVP,MVP的优势才能凸显出来,这样连贯性的...

叫我丹尼尔
2017/12/02
0
0
So,You think you kown MVP (3)……在Android中使用MVC(上)

我想把这句话设置成固定的开篇: 为什么要先介绍MVC?如果你要想更佳深刻的理解MVP,并在实际开发中灵活的应用,那么就要先了解它的低配版MVC,他俩只是一步之遥,先了解MVC再学习MVP,MVP的...

不能用真名
2017/11/29
0
0
design patterns - 从头讲解MVC模式

和一般文章不同,本文不依赖于任何现有的框架,也不试图陷入冗长的发展历史,而是完全从头开始,以一个尽可能小但是可以说明问题的案例,以此讲清楚MVC这个历史悠久、变型极多的技术理念。M...

2018/01/10
0
0

没有更多内容

加载失败,请刷新页面

加载更多

安全组和云防火墙的区别

前言 熟悉云平台的朋友可能都会注意到这样一个事情:无论公有云还是私有云,创建虚拟机的时候都需要选择安全组,来对虚拟机进行安全防护;有的云平台在VPC里,还能选择防火墙,ZStack在3.6版...

ZStack社区版
16分钟前
1
0
教育性app开发的重要性和好处

在这个精通技术的世界中,流行的app主导着无聊的教育系统。当我们将技术和教育结合在一起时,它将带来当代以及强大的学习资源。因此,将教育移动app集成到您的学习过程中,并根据自己的信念把...

a429011717
16分钟前
1
0
IE6/7/8如何兼容CSS3属性

本文转载于:专业的前端网站➩IE6/7/8如何兼容CSS3属性 最近在工作中总是要求IE8兼容CSS3属性,在网上搜了搜主要是引入了一个htc文件(ie-css3.htc或者PIE.htc。个人认为这两个文件的作用差不...

前端老手
32分钟前
2
0
手把手教你ALLEGRO的约束规则的设置教程!

约束规则的设置 分三步, 定义规则(一、基本约束规则设置:1、线间距设置;2、线宽设置;3、设置过孔;4、区域约束规则设置;5、设置阻抗;6、设置走线的长度范围;7、设置等长:7.1、不过电阻的NET 等...

demyar
33分钟前
3
0
完美解决H5滚动滑动穿透方案:不使用系统滚动

网上有很多黑科技解决这个问题,都不是从根本去解决,例如通过js控制弹出时html加上position:fixed; 弹窗关闭后再去掉该样式,总觉得不太对,像是打补丁。 今天终于找到了滚动穿透的原因和完...

未来cc
38分钟前
5
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部