1、同步模块模式
随着页面功能的增加,系统的业务逻辑越来越复杂。多人开发的功能经常耦合在一起。有时分配任务给多人实现的时候,常常因为某一处功能耦合了很多人的代码,出现排队修改的现象,这很不利于团队开发。
模块化:将复杂的系统分解成高内聚,低耦合的模块,使系统开发变得可控、可维护、可拓展、提高模块的复用率。
同步模块模式:请求发出后,无论模块是否存在,立即执行后续的逻辑,实现模块开发中对模块的立即引用。
要实现模块化开发,首先又有一个模块管理器,他管理者模块的创建与调度。
对于模块调用方法,参数可以分为两部分,依赖模块和回调执行函数(最后一个参数),它的实现原理就是遍历并获取所有的依赖模块,并一次保存在依赖模块列表中,然后,价格这些依赖模块作为参数传入执行函数中执行。
//定义模块管理器单体对象 var F=F||{}; //定义模块方法,理论上是放在闭包里面实现的 F.define=function(str,fn){ } //创建模块,理论上也不能这样直接调用 F.define("string",function(){ return { trim:function(str){ }//将返回的对象挂在string上 } }) //模块调用方法 F.module=function(){ } //模块调用 F.module(["dom",document],function(dom,doc){ })
2、异步模块方式
同步模块模式:请求发出后,继续其他业务逻辑,知道模块加载完成执行后续的逻辑,实现模块开发中对模块的立即引用。
浏览器环境不同于服务器环境,在浏览器中对文件的加载是异步的。
(function(F){ //模块缓存器。存储已创建模块 var moduleCache={} })((function(){ //创建模块管理器对象F,并保存在全局作用域中 return window.F={}; })()) /* *创建一个module方法,集模块创建方法于一身。在这个方法中要遍历所有依赖模块, *并判断所有模块都存在才执行回调函数,否则加载相应的文件,直到文件加载完成后 *才执行回调函数 */ F.module=function(url,deps,callback){ //中间用到两个方法loadmodule方法和setModule方法。 //loadmodule方法目的是加载依赖模块对应的文件并执行回调函数。 //setModule方法就是执行回调函数 }
这一块,感觉书上的代码有问题。读不通
3、组件化(widget)模式
Widget:(web widget指的是一块可以在任意页面中执行的代码块)Widget模式是指借用web Widget思想将页面分解成部件,针对部件开发,最终组合成完整的页面。
模块化开发使页面的功能细化,逐一实现每个微功能,完成系统需求,这是一种很好的编程实践,对于页面视图又是如何实现的呢。
首先将页面粒度化,分解成一个个组件,当然一个组件也对应着一个模块,一个完整的组件包含该模块的完整视图和一套完整的功能。因此,Widget模式开发中的一个组件就要对应一个文件了,而不是某个功能或者某个视图,因此,在这个组件中,要做两件事:创建视图,添加相应的功能。
创建视图就要借用到简单模板模式的思想,用服务器端请求来的数据格式化我们视图模板实现对视图的创建。然后处理数据,获取模板,编译执行。
//模块调用 F.module("lib/template",function(){ //模板引擎,处理数据和编译路口 var _TplEngine=function(str,data){ //当中调用_getTpl来获取模板,并将data传入最后生成的函数中。 }, //获取模板,str模板容器id,或者模板字符串 _getTpl=function(str){ //当中调用编译函数 }, //处理模板,明确哪些内容是要替换的 _dealTpl=function(){}, //编译执行,将模板处理方法_dealTpl得到的模板字符串编译成最终的模板 _compileTpl=function(str){}, })
缺点:将视图与创建视图所需的数据以及组件的交互逻辑耦合在一起,这时候就该mvc上场了。
4、MVC模式
MVC:即模型(module)-视图(view)-控制器(controller),用一种将业务逻辑,数据、视图分离的方式和组织架构代码。
$(function(){ //初始化MVC对象 var MVC=MVC||{}; /* *都是立即执行函数,方便提供接口 */ //初始化MVC数据模型层 MVC.model=function(){ //内部数据对象 var M={}; //写在服务器端的数据 M.data={}; //配置数据,页面加载时提供 M.conf={}; //返回数据模型层的对象的操作方法 return{ // getData:function(m){ return M,data[m]; }, //设置配置数据 setConf:function(c,v){ M.conf[c]=v; return this; } } }(); //初始化MVC视图层 MVC.view=function(){ //模型数据层对象操作方法的引用 var M=MVC.model; //内部视图创建方法对象 var V={}; //获取视图接口方法 return function(v){ //根据视图名称返回视图 V[v](); } }(); //初始化MVC控制层,第一是创建视图;第二是添加交互与动画特效 MVC.ctrl=function(){ //模型数据层对象操作方法的引用 var M=MVC.model; //视图数据层对象操作方法的引用 var V=MVC.view; //控制器创建方法对象 var C={}; }(); })
5、MVP模式
MVP:即模型(module)-视图(view)-管理器(Presenter),view层不直接引用Model层类的数据,而是通过Presenter层实现对Model层内的数据访问。即所有层次的交互都发生在Presenter层中。
MVC模式开发中,视图层常常因渲染页面而直接引用数据层内的数据,对于发生的这一切,控制器常常不得而知。因此数据层内的数据修改,常常在控制器不知情的情况下影响到视图层的呈现。
(function(window){ //MVP构造函数 var MVP=function(){}; //数据层 MVP.model=function(){ //内部数据对象 var M={}; //写在服务器端的数据 M.data={}; //配置数据,页面加载时提供 M.conf={}; //返回数据模型层的对象的操作方法 return{ // getData:function(m){ return M,data[m]; }, //设置配置数据 setConf:function(c,v){ M.conf[c]=v; return this; } } }; //视图层 MVP.view=function(){ //只留下一些模板处理方法,解析字符串,渲染模板,中间不传入数据 }; //管理层 MVP.presenter=function(){ var V=MVP.view; var M=MVP.model; var C={ //一个属性,就是代表一类模板,获取数据,处理模板 }; return{ //执行方法 init:function(){ for(var i in C){ C[i] && C[i](M,V,i); } } } }; //MVP入口 MVP.init=function(){ this.presenter.init(); }; //暴露MVP对象,这样既可在外部访问MVP window.MVP=MVP; })(window)
模块开发中的应用
F.module("lib/MVP",function(dom,doc){ var MVP=function(){}; //........ return MVP; })
6、MVVM模式
MVVM模式:模型-视图-视图模型:为视图层量身定做一套视图模型,并在视图模型中创建属性和方法,为视图层绑定数据并实现交互。
既然我们能够将视图层独立出来,那么可不可以通过创建视图反过来控制管理器实现组件的需求。对于视图层(V)内的元素是要被视图模型(VM)层监听的,因此我们在视图模型(VM)层中实现对这些元素的监听,并为他们绑定行为。