MVC MVP MVVM

MVC

 　　比我还大的东西都不会太难,好比mvc,mvc的区分方式很是好理解,或许他也仅仅只是一个分层方式....从对象或者说组件的角度来看,属性,方法和事件三者是必须的,那么将其分为一种设计分层来讲应该就是mvc

M

　　软件,产品,对象,不管什么离不开内容,就算是一个杂乱无章的一断字节,也须要将其进行整理,返回的结果就称之为M,大多数状况下,M来自数据库

C

　　面向对象的方式,少不了事件的建立,固然就算是面向过程也会有事件的产生,事件,具体的方法,逻辑,他可能对模型有影响,也可能对展现有影响,在面向对象中,她可能会依赖属性,无论怎样,业务逻辑的体现,在这里

V

　　视图,尽管称之为视图,我仍是将它理解为监控,互动,负责捕捉页面与人的交互行为(固然渲染和监控都是视图的责任,我只是调换了一下顺序),在V中将会产生各类不可控,不稳定的事件(你没法知道什么时候,何地甚至前后顺序),他们会出发你C中定义的方法

沟通

　　固然三者间的沟通规则,通常会要求使用万金油的接口,大多数状况下会选择实现(看一下你写的winform或者swing)

 

　　MVC仅仅制做了总体的划分规则,更详细的并无太多的帮助,以致于如今当咱们建立一个web,swing,winform工程时,已是MVC了,相对于曾经的model1时代,只要你在数据库分离,提取出模型,也能成为MVC,更细致的规则必须须要具体分析,毕竟context is everything

MVP

　 没有用过MVP之类的框架,但这不影响我去胡扯- -

p与c

　　依然将M理解为属性,其实对属性的处理,通常都是引用式的处理,你能够拥有它,建立他,修改它,但你不能删除他,好比

　　你能够获取对象A,你的确可让属性a制空,可是你不能删除对象A...固然删除程序中的一个对象,这是垃圾回收器的事,个人意思是若是这是逻辑上的对象呢?

若是真的在控制器中缓存了A,模型的删除将会形成逻辑上的错误,处理的方式很简单,面向接口,不在拥有模型A的引用,所有交给M(这不是P要解决的),换到另外一边看(C与V),在展现中,展现的效果会随意进行修改的,好比常用的.tofixed,format甚至render(你还能够想的更大一些),问题在于这些展现数据的变动是否须要由V来进行更改?P的概念就在这里,V不须要且不能去修改M,他须要的仅仅是展现

栗子

　　我将这种处理方式,理解为MVP,V绝壁不去管你你来的是什么,反正我就是将你展现出来就是了,UI线程所须要作的就是展现和互动

MVVM

　　绑定是关键,虽称之为下降依赖,V与VM绝壁是仅仅依赖在一块儿的,从cs端的程序来看很是好理解,但谁让我是搞web的类

VM

　　有一个很火的词,先后端分离,专门用来吐槽上面的一种作法,他们认为,后端不须要去搞显示逻辑,换句换说,V与C都是前端的。。。说的好像有点高深,若是你用过easyui,ext或者其余组件,其实你就已经先后端分离了

使用各类组件,必需要一个json对象,然后经过这个json对象,产生dom,产生了展现效果,他有点像jsp,不过在运行的时候一个在后端,一个在js中,若是你使用了他们,而且被告知本身的系统是MVC,是否会认为,在这种状况下,这个C压根什么都没干吗,service和dao彻底就是一个东西,没错,你被忽悠了,你的C在前端,大家已经先后端分离了

　　有且只有VC在一块儿才能使用VVM

　　想象一下easyui,或者咱们平时建立的组件,经过接口(选择器)去选择dom节点,然后为他赋值,并为他设置方法和属性,既然VC已经在一块儿了,为何还要经过接口(选择器)去寻找呢?这里的依赖应该是容许的吧...看个easyui的方式

这是一个前端面向接口规范(面向选择器)的作法,看起来没有什么问题,若是你用过你就会发现,难以维护,由于最终展现的效果跟你写的原形根本不同,为了寻找id="cc"的具体实现,你须要找到那个js,并找到他的实现,他并不想jsp/asp那样,能够简单的进行猜想,那若是是这种方式呢?

至少,你不须要再去点击js而后查看实现了吧...这就是一种VVM的实现,发现没,VVM之间能够超级依赖的,不是全部js都能识别data-options是什么的,他可不是一个规范,一个接口

vvm所作的就是自动查询节点的功能,由于你已经写在他脸上了,它的关键就是常说的绑定

　　固然easyui可不是一个标准的前端MVVM,只是核心点,有那么点意思- -就像大多数前端要求先后端分离,使用easyui,ext的小做坊的程序猿可真感觉不要到他们的优点

　　很显然前端MVVM能够帮助咱们去梳理业务逻辑结构,若是要是用他们的话,了解一下原理,也是必须的