框架与库的最大区别就是代码的风格确认,库只是页面级别的选择,而架构则关注于整个程序的设计

MVC

　　作为软件中的99口诀,软件设计要是没个mvc就好像不是正规军一样,前端也是这样,将html理解为view,js理解为controller,js的通讯(主要指ajax)交互理解为model的获取,那么前端就是一个标准的mvc架构,其写法大致是这样的

html/view:

 <button class="btn btn-info" id='save'>提交</button>

js/controller:

    $('#save').click(function() {$.post('/api/save').done(function(res) {consoel.log(res);}).fail(function(error) {consoel.log(error);})});

ajax就是与model的交互

值得注意的是浏览器是基于事件触发的,一切响应都基于事件,与我们自定义的函数最大的区别就是其第一个参数一定为event,所以也就可以明确的表明js通过选择器进行事件的赋值,以达到控制的目的,so...作为一个前端理解为mvc的架构师,就需要对其写法进行简单的确定,比如:

js/controller-->更明确的controller结构

(function(){//初始化//将事件业务描述化function save(event){}$.controller.a={'#save':{click:save}}
})()

$.controller为所有的控制器,其中的a就是改页面的controller的内容,而后在结合简单的架构封装,比如路由或者在html上增加加载选项,就可以让这个js作用于当前的view,当然这种写法是用来描述的,在js加载器不断完善,已融入为架构的一部分的情况下,controller早就可以更加的对象化,比如这样:

define(function(require, exports, module) {//初始化参数
module.exports = {'#save':{click:save}}//事件业务化function save(event) {//....
    }})

看着很熟悉吧,没错,用了seajs,加载器是架构的一部分,程序的设计就是api的设计(无视如何掉用的地方),单说这样的写法是不是让人感觉更加的mvc呢?

总之,前端的mvc大致就是将html看作view,一切与view无关的事情通通忽略(根据架构,可能会有1～2行的代码用以描述controller),将js看作controller,其通过选择器(即mvc中的接口)的方式获取view并进行操作,并通过ajax与后台(model)进行交互(M的概念一致比较弱化),以此达到解耦的目的

当然前端mvc包含mvc的所有缺点(依赖接口,更多的是接口太多,甚至无法固定接口),尤其在前端这种特殊的业务环境下,在其业务描述必定基于事件(这在前端肯定避免不了)的前提下,相似的业务总会让人措手不及,controller的描述也就变的无比蛋疼...

mvvm

　　解决问题的办法永远都是分层,mvvm也是一样,将基于事件的驱动,修正为基于方法,甚至基于属性,就是一个更好的方式,mvvm的控制器并不会去监听浏览器的事件,而是监听一个属性表,由浏览器的事件修改属性,以触发控制器中的方法,增加了一层控制业务的属性,而这层属性被称为vm

举个栗子:

假设一个分页的业务,在两种架构中m和v都一样,则:

define(function(require, exports, module) {//初始化参数var page=1,totalpage=10;module.exports = {'#pre':{click:pre},'#next':{click:next},'#last':{click:last},'#first':{click:first}}//事件业务化function pre(event) {page=(page===1)?1:page-1;exec();}function next(event){page=(page===totalpage)?totalpage:page+1;exec();}//...last,first//总会有大量的通用业务,比如这个function exec(){$.ajax('/api/users',{page:page,})}})

依赖于属性的变化,so...

define(function(require, exports, module) {//初始化参数var page=1,totalpage=10;module.exports = {'#pre':{click:pre},'#next':{click:next},'#last':{click:last},'#first':{click:first}}//事件业务化function pre(event) {page=(page===1)?1:page-1;}function next(event){page=(page===totalpage)?totalpage:page+1;}//...last,first//真正的业务,需要监控page属性$.watch('page',function(newv,oldv){$.ajax('/api/users',{page:page})});
})

无视$.watch的存在,至少我们知道那里面包含的就是真正的业务逻辑,而所谓的事件,都只是用来修改属性的对吧,就目前来讲,他跟mvc还是很像,如果感觉到mvvm中的事件都只是修改属性的特点的化,结合dom赋值的特点,在view中通过onclick属性修改属性标签的化,就能够将所有的接口(选择器)全部的干掉...换而研制,依赖vm的变化,而非事件的变化,将业务的重点至于方法中而非事件中

如果了解js,html,css分离肯能会感觉到,在html中写onclik是不是太耦合了...没错,单说耦合的话的确是这样,但在前端大多数场景中,这种耦合是有必要的(尼玛都是一个人写,又不像前后端分离那样明显),这种耦合可以消灭所有的接口建立,也就是所谓了无选择器和自动执行的特点

mvp

mvc,mvp,mvvm进场在一起比较的三胞胎,前端似乎不流行mvp－。－

假设mvc是基础,基于vc的强化叫mvvm,那基于vm的强化就叫mvp,model的获取是通过ajax,前端根model已无法在进行太多的封装(在整就到后台了),so...好像还是没有解释mvp－。－

mvp大致就是充血模式吧,就酱紫

　　当然了,前端mvc和mvvm是各位大神根据实践一步步总结出来的,而非想像上面简单的分析出来的,这里只是架构风格和业务写法上做的简单分析,更重要的区别还是要给予实践才能感受到,任何架构都有适用的范围,百数内的排序还是快排好,买名牌还是实体店放心,万能架构还是算了吧