标签：
随着页面功能的增加，系统的业务逻辑越来越复杂。多人开发的功能经常耦合在一起。有时分配任务给多人实现的时候，常常因为某一处功能耦合了很多人的代码，出现排队修改的现象，这很不利于团队开发。
模块化：将复杂的系统分解成高内聚，低耦合的模块，使系统开发变得可控、可维护、可拓展、提高模块的复用率。
同步模块模式：请求发出后，无论模块是否存在，立即执行后续的逻辑，实现模块开发中对模块的立即引用。
要实现模块化开发，首先又有一个模块管理器，他管理者模块的创建与调度。
对于模块调用方法，参数可以分为两部分，依赖模块和回调执行函数（最后一个参数），它的实现原理就是遍历并获取所有的依赖模块，并一次保存在依赖模块列表中，然后，价格这些依赖模块作为参数传入执行函数中执行。
//定义模块管理器单体对象 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){ })
同步模块模式：请求发出后，继续其他业务逻辑，知道模块加载完成执行后续的逻辑，实现模块开发中对模块的立即引用。
浏览器环境不同于服务器环境，在浏览器中对文件的加载是异步的。
(function(F){ //模块缓存器。存储已创建模块 var moduleCache={} })((function(){ //创建模块管理器对象F,并保存在全局作用域中 return window.F={}; })()) /* *创建一个module方法，集模块创建方法于一身。在这个方法中要遍历所有依赖模块， *并判断所有模块都存在才执行回调函数，否则加载相应的文件，直到文件加载完成后 *才执行回调函数 */ F.module=function(url,deps,callback){ //中间用到两个方法loadmodule方法和setModule方法。 //loadmodule方法目的是加载依赖模块对应的文件并执行回调函数。 //setModule方法就是执行回调函数 }
这一块，感觉书上的代码有问题。读不通
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上场了。
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={}; }(); })
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;
})
MVVM模式：模型-视图-视图模型：为视图层量身定做一套视图模型，并在视图模型中创建属性和方法，为视图层绑定数据并实现交互。
既然我们能够将视图层独立出来，那么可不可以通过创建视图反过来控制管理器实现组件的需求。对于视图层（V）内的元素是要被视图模型（VM）层监听的，因此我们在视图模型（VM）层中实现对这些元素的监听，并为他们绑定行为。
标签：
原文地址：http://www.cnblogs.com/huansky/p/5679034.html
