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可以帮助我们去梳理业务逻辑结构,如果要是用他们的话,了解一下原理,也是必须的
