1.每个人都可以做成为架构设计师

不懂软件的和刚入行的人们一听到架构设计，都认为是非常的高大上课题，是一个遥不可及的领域，一般人是不能做的。听起来云里雾里的，第一印象除了来自微软，阿里这些NB的公司里面的人其余的都不能做出架构似的，这是一种先入为主的思想，因为大家都在强调架构师的重要性，他的薪资有多么的高，在整个社会对他的认定导致很多人对架构设计望而生畏。放正自己的心态其实架构设计并没有多么的复杂。我们是从编码入行的，在编码实现功能的过程中我们或多或少的设计了属于自己的软件架构了。

为什么说软件架构师需要多少年的工作经验，因为软件架构就是系统的草图，不仅是代码编写而且包括部署，运行、开发等这些方面进行设计，目的是为了保证软件开发、运行、扩展、性能、安全、伸缩等等质量的一个保证。只要在编码过程中不仅仅要提升编码的质量而且要留心其他方面的知识积累与学习，用不了多久你也能成为一位优秀的架构设计师。

2.什么是架构设计

我们要成为架构设计师我们需要了解什么是架构设计。简单一点，架构设计就是一个系统的草图，描述了构成系统的抽象组件，以及各个组件之间的是如何进行通讯的，这些组件在实现过程中可以被细化为实际的组件比如类或者对象。在面向对象领域中，组件之间的联通通常面向于接口实现的。

在“软件架构简介”中David Garlan 和Mary Shaw 认为软件架构师有关如下问题进行设计的：“计算的算法和数据结构之外，设计并确定系统整体结构，结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。”

架构和结构会难以区分，明确一点架构不是结构，IEEE把架构定义为“系统在其环境中的最高层概念”架构还包括系统完整性、经济约束条件、审美需求和样式等。在Rational Unified Process 中对软件架构的解释：软件架构指系统重要构建的组织或结构，这些重要的构建通过接口与其他构建进行交互。

总体来说软件架构对软件从整体到部分的描述，从开发到运行再到后期扩展的描述，从性能和安全可靠性进行描述。

3.架构设计为了解决什么问题
开发之初逻辑设计阶段要确定系统如何开发，整个系统融合为一个系统开发还是从业务角度将系统拆分为几个独立的子系统。在即将进入开发的时候关注了数据是如何持久化的，以及数据库选型、以及非数据库文件的存储格式，等这些存储方案的确定。在开发过程中我们要关注如何保证开发质量，如何分层，代码可扩展性，使用的设计模式，依赖了那些框架，开发语言这些方向的确定。开发完成之后进入运行阶段，如何在架构设计的时候保证运行期间的质量属性、性能、可伸展性等，主要是系统运行进程的划分，以及进程之间通过线程来通信。同时如果系统并非是单机运行，还需考虑系统的物理部署，系统部署在那个服务器上，这些服务器配置性能怎样能否胜任系统的运行，操作系统选型，以及系统部署的网络拓扑图，还有就是保证数据安全的数据备份怎样设计的。

以上五个问题是从五个角度来确定架构以及架构设计需要解决的问题。

4.架构设计的五视图法

我们刚才从五个不同的角度知道架构设计需要解决的问题，那么使用五视图法就更加系统的分析设计我们架构了：











从这幅图里面我们可以看出架构设计五视图中各个角度需要解决的问题了，并且可以看出他们之间的联系了。

5.后期如何使用使用架构设计

无论多么好的架构如果只是为了设计完成任务都是毫无意义的，我们设计出来的架构无论是好或不好我们首先需要按照架构设计来完成系统的开发，作为项目的Leader就需要严格按照架构设计出来的标准进行检查，无论我们的开发模式敏不敏捷，到一定时间都有一个里程碑的阶段，到了这个阶段Leader牵头严格按照架构设计文档中相应的章节对开发出来的系统进行检查，及早发现问题及早解决，不要把问题向后面推。


1）物理架构
    物理架构的目的是确定物理节点和物理节点的拓扑结构；其中物理节点包括服务器、PC机、专用机、软件安装部署烧写以及系统软件的选型；拓扑结构明确物理节点的关系。

2）运行架构
    运行架构的目的是确定控制流和控制流的组织；其中控制流包括进程、线程、服务程序；控制流组织包括系统的启动与停机、控制流通讯、同步与加锁。

3）开发架构
    开发架构的目的是确定程序单元以及程序单元的组织结构；其中程序单元包括源文件、配置文件、程序库、框架、目标单元；程序单元组织包括project划分、project目录结构、编译依赖关系。

4）逻辑架构
    逻辑架构的目的是职责的划分，并明确其与协作关系；其中职责的划分注意逻辑的分层、子系统以及关键类的定义；协作的定义关注接口的定义与协作关系的明确。

5）数据模型
    数据架构的目的是确定要存储的数据以及存储格式；其中存储的数据可以是文件、关系数据库、实时数据库；存储格式包括文件格式、数据库图表。
 
来自：http://blog.csdn.net/degwei/ar ... 89444 查看全部

踏入公司尤其是大型互联网公司就会发现，公司的系统都由成千上万大大小小的服务组成，各服务部署在不同的机器上，由不同的团队负责。这时就会遇到两个问题：
1）要搭建一个新服务，免不了需要依赖他人的服务，而现在他人的服务都在远端，怎么调用？
2）其它团队要使用我们的服务，我们的服务该怎么发布以便他人调用？下文我们将对这两个问题展开探讨。 
1 如何调用他人的远程服务？

由于各服务部署在不同机器，服务间的调用免不了网络通信过程，服务消费方每调用一个服务都要写一坨网络通信相关的代码，不仅复杂而且极易出错。

如果有一种方式能让我们像调用本地服务一样调用远程服务，而让调用者对网络通信这些细节透明，那么将大大提高生产力，比如服务消费方在执行helloWorldService.sayHello(“test”)时，实质上调用的是远端的服务。这种方式其实就是RPC（Remote Procedure Call Protocol），在各大互联网公司中被广泛使用，如阿里巴巴的hsf、dubbo（开源）、Facebook的thrift（开源）、Google grpc（开源）、Twitter的finagle等。

要让网络通信细节对使用者透明，我们自然需要对通信细节进行封装，我们先看下一个RPC调用的流程：





 

1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。


RPC的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。
  
1.2  怎么对消息进行编码和解码？
1.2.1 确定消息数据结构

上节讲了invoke里需要封装通信细节，而通信的第一步就是要确定客户端和服务端相互通信的消息结构。客户端的请求消息结构一般需要包括以下内容：

1）接口名称

在我们的例子里接口名是“HelloWorldService”，如果不传，服务端就不知道调用哪个接口了；

2）方法名

一个接口内可能有很多方法，如果不传方法名服务端也就不知道调用哪个方法；

3）参数类型&参数值

参数类型有很多，比如有bool、int、long、double、string、map、list，甚至如struct（class）；

以及相应的参数值；

4）超时时间

5）requestID，标识唯一请求id，在下面一节会详细描述requestID的用处。

同理服务端返回的消息结构一般包括以下内容。

1）返回值

2）状态code

3）requestID

1.2.2 序列化

一旦确定了消息的数据结构后，下一步就是要考虑序列化与反序列化了。

什么是序列化？序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程。

什么是反序列化？将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程。

为什么需要序列化？转换为二进制串后才好进行网络传输嘛！为什么需要反序列化？将二进制转换为对象才好进行后续处理！

现如今序列化的方案越来越多，每种序列化方案都有优点和缺点，它们在设计之初有自己独特的应用场景，那到底选择哪种呢？从RPC的角度上看，主要看三点：
1）通用性，比如是否能支持Map等复杂的数据结构；
2）性能，包括时间复杂度和空间复杂度，由于RPC框架将会被公司几乎所有服务使用，如果序列化上能节约一点时间，对整个公司的收益都将非常可观，同理如果序列化上能节约一点内存，网络带宽也能省下不少；
3）可扩展性，对互联网公司而言，业务变化快，如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，删除老的字段，而不影响老的服务，这将大大提供系统的健壮性。

目前国内各大互联网公司广泛使用hessian、protobuf、thrift、avro等成熟的序列化解决方案来搭建RPC框架，这些都是久经考验的解决方案。
  查看全部

用户画像是根据用户社会属性、生活习惯和消费行为等信息而抽象出的一个标签化的用户模型。用户画像建立的过程就是添加相应的标签，在数据挖掘领域称为标签化。标签是通过对用户信息分析而得到的高度精炼的特征标识。
 
比如唯品会、淘宝可根据用户的购物习惯，买了什么产品，根据产品的属性，最终都会形成不同标签，例如高低价值、男女等标签，用这些标签就可以形成用户画像，这就是贴标签的过程。

综合而言，添加标签方法主要有4种：

（1）固有基本属性标签

比如人口统计学的属性信息，这些信息包括性别、年龄、职业、学历、籍贯、婚姻、收入、房产等信息。如果你有客户的身份证号码，你就可以提取出用户的籍贯、出生日期、性别等信息。

（2）通过基础信息处理得到标签
比如说根据你的出生日期就可以推算出星座、生肖、性格等，因为我们知道不同的星座会有不同的性格或者做事风格，如处女座追求完美。再例如你家庭地址在北京二环内，那么可能就被打上一个标签——“土豪”或者其他标签。

（3）通过用户行为推测标签
例如用户购买了高尔夫球用品，你可能就是高端商务人士或老板，那么可能会被贴上高收入、高端等标签。再例如如果购买了卫生巾的客户，那么可能就被贴上女性、非孕妇等标签，这就是根据用户的一些行为特征推测添加的标签。

（4）数据挖掘建模输出标签
例如从几个指标综合对用户进行聚类分析，最终会得到不同用户群体，每个群体就有一个标签，属于什么类；再比如流失预测模型，模型最终输出流失概率得分，我们可以根据流失概率得分的高低，划分为高流失用户、中流失用户、低流失用户、不流失用户等标签，这些都是最终得到一个标签，也就是前面所说的标签化、贴标签。
综合而言，贴标签不一定要用到数据挖掘高大上的方法，简单通过一个有业务价值的指标，如消费额、消费频次都能得到非常有业务价值的用户分类。不论黑猫还是白猫，能抓老鼠的猫就是好猫，同理不论高级的方法还是简单的方法，只要能够解决问题的方法就是好方法。
  查看全部

1.概述

    在软件开发中也常常遇到类似的情况，实现某一个功能有多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能。如查找、排序等，一种常用的方法是硬编码(Hard Coding)在一个类中，如需要提供多种查找算法，可以将这些算法写到一个类中，在该类中提供多个方法，每一个方法对应一个具体的查找算法；当然也可以将这些查找算法封装在一个统一的方法中，通过if…else…或者case等条件判断语句来进行选择。这两种实现方法我们都可以称之为硬编码，如果需要增加一种新的查找算法，需要修改封装算法类的源代码；更换查找算法，也需要修改客户端调用代码。在这个算法类中封装了大量查找算法，该类代码将较复杂，维护较为困难。如果我们将这些策略包含在客户端，这种做法更不可取，将导致客户端程序庞大而且难以维护，如果存在大量可供选择的算法时问题将变得更加严重。

例子1：一个菜单功能能够根据用户的“皮肤”首选项来决定是否采用水平的还是垂直的排列形式。同事可以灵活增加菜单那的显示样式。

例子2：出行旅游：我们可以有几个策略可以考虑：可以骑自行车，汽车，做火车，飞机。每个策略都可以得到相同的结果，但是它们使用了不同的资源。选择策略的依据是费用，时间，使用工具还有每种方式的方便程度 。

2.问题

如何让算法和对象分开来，使得算法可以独立于使用它的客户而变化？


3.解决方案

策略模式：定义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。也称为政策模式(Policy)。（Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it. ）

策略模式把对象本身和运算规则区分开来，其功能非常强大，因为这个设计模式本身的核心思想就是面向对象编程的多形性的思想。

4.适用性

当存在以下情况时使用Strategy模式
1）• 许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统需要动态地在几种算法中选择一种。
2）• 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间 /时间权衡的算法。当这些变体实现为一个算法的类层次时 ,可以使用策略模式。
3）• 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
4）• 一个类定义了多种行为 , 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

5.结构





 
6.模式的组成
 
环境类(Context):用一个ConcreteStrategy对象来配置。维护一个对Strategy对象的引用。可定义一个接口来让Strategy访问它的数据。抽象策略类(Strategy):定义所有支持的算法的公共接口。 Context使用这个接口来调用某ConcreteStrategy定义的算法。具体策略类(ConcreteStrategy):以Strategy接口实现某具体算法。

7.效果

Strategy模式有下面的一些优点：

1) 相关算法系列 Strategy类层次为Context定义了一系列的可供重用的算法或行为。 继承有助于析取出这些算法中的公共功能。
2) 提供了可以替换继承关系的办法： 继承提供了另一种支持多种算法或行为的方法。你可以直接生成一个Context类的子类，从而给它以不同的行为。但这会将行为硬行编制到 Context中，而将算法的实现与Context的实现混合起来,从而使Context难以理解、难以维护和难以扩展，而且还不能动态地改变算法。最后你得到一堆相关的类 , 它们之间的唯一差别是它们所使用的算法或行为。 将算法封装在独立的Strategy类中使得你可以独立于其Context改变它，使它易于切换、易于理解、易于扩展。
3) 消除了一些if else条件语句 ：Strategy模式提供了用条件语句选择所需的行为以外的另一种选择。当不同的行为堆砌在一个类中时 ,很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。含有许多条件语句的代码通常意味着需要使用Strategy模式。
4) 实现的选择 Strategy模式可以提供相同行为的不同实现。客户可以根据不同时间 /空间权衡取舍要求从不同策略中进行选择。

Strategy模式缺点:

1)客户端必须知道所有的策略类，并自行决定使用哪一个策略类:  本模式有一个潜在的缺点，就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时 , 才需要使用Strategy模式。
2 ) Strategy和Context之间的通信开销 ：无论各个ConcreteStrategy实现的算法是简单还是复杂, 它们都共享Strategy定义的接口。因此很可能某些 ConcreteStrategy不会都用到所有通过这个接口传递给它们的信息；简单的 ConcreteStrategy可能不使用其中的任何信息！这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样问题 , 那么将需要在Strategy和Context之间更进行紧密的耦合。
3 )策略模式将造成产生很多策略类：可以通过使用享元模式在一定程度上减少对象的数量。 增加了对象的数目 Strategy增加了一个应用中的对象的数目。有时你可以将 Strategy实现为可供各Context共享的无状态的对象来减少这一开销。任何其余的状态都由 Context维护。Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享的 Strategy不应在各次调用之间维护状态。

8.实现

1)出行旅游：
 
uml：





 
代码实现：
<?php
/**
* 策略模式
* 定义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化
*
*/


/**
* 出行旅游
*
*
*/
interface TravelStrategy{
public function travelAlgorithm();
}


/**
* 具体策略类(ConcreteStrategy)1：乘坐飞机
*/
class AirPlanelStrategy implements TravelStrategy {
public function travelAlgorithm(){
echo "travel by AirPlain", "<BR>\r\n";
}
}


/**
* 具体策略类(ConcreteStrategy)2：乘坐火车
*/
class TrainStrategy implements TravelStrategy {
public function travelAlgorithm(){
echo "travel by Train", "<BR>\r\n";
}
}

/**
* 具体策略类(ConcreteStrategy)3：骑自行车
*/
class BicycleStrategy implements TravelStrategy {
public function travelAlgorithm(){
echo "travel by Bicycle", "<BR>\r\n";
}
}



/**
*
* 环境类(Context):用一个ConcreteStrategy对象来配置。维护一个对Strategy对象的引用。可定义一个接口来让Strategy访问它的数据。
* 算法解决类，以提供客户选择使用何种解决方案：
*/
class PersonContext{
private $_strategy = null;

public function __construct(TravelStrategy $travel){
$this->_strategy = $travel;
}
/**
* 旅行
*/
public function setTravelStrategy(TravelStrategy $travel){
$this->_strategy = $travel;
}
/**
* 旅行
*/
public function travel(){
return $this->_strategy ->travelAlgorithm();
}
}

// 乘坐火车旅行
$person = new PersonContext(new TrainStrategy());
$person->travel();

// 改骑自行车
$person->setTravelStrategy(new BicycleStrategy());
$person->travel();

?> 2)排序策略:某系统提供了一个用于对数组数据进行操作的类，该类封装了对数组的常见操作，

如查找数组元素、对数组元素进行排序等。现以排序操作为例，使用策略模式设计该数组操作类，

使得客户端可以动态地更换排序算法，可以根据需要选择冒泡排序或选择排序或插入排序，

也能够灵活地增加新的排序算法。
 
9.与其他相关模式

1）状态模式

策略模式和其它许多设计模式比较起来是非常类似的。策略模式和状态模式最大的区别就是策略模式只是的条件选择只执行一次，而状态模式是随着实例参数（对象实例的状态）的改变不停地更改执行模式。换句话说，策略模式只是在

对象初始化的时候更改执行模式，而状态模式是根据对象实例的周期时间而动态地改变对象实例的执行模式。

•可以通过环境类状态的个数来决定是使用策略模式还是状态模式。
•策略模式的环境类自己选择一个具体策略类，具体策略类无须关心环境类；而状态模式的环境类由于外在因素需要放进一个具体状态中，
以便通过其方法实现状态的切换，因此环境类和状态类之间存在一种双向的关联关系。
•使用策略模式时，客户端需要知道所选的具体策略是哪一个，而使用状态模式时，客户端无须关心具体状态，环境类的状态会根据用户的操作自动转换。
•如果系统中某个类的对象存在多种状态，不同状态下行为有差异，而且这些状态之间可以发生转换时使用状态模式；
如果系统中某个类的某一行为存在多种实现方式，而且这些实现方式可以互换时使用策略模式。

2）简单工厂的区别：点击打开链接

工厂模式是创建型模式 ，它关注对象创建，提供创建对象的接口. 让对象的创建与具体的使用客户无关。
策略模式是对象行为型模式 ，它关注行为和算法的封装 。它定义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换。使得算法可独立于使用它的客户而变化

用我们上面提到旅行的例子：
我们去旅行。策略模式的做法：有几种方案供你选择旅行，选择火车好呢还是骑自行车，完全有客户自行决定去构建旅行方案（比如你自己需要去买火车票，或者机票）。而工厂模式是你决定哪种旅行方案后，不用关注这旅行方案怎么给你创建，也就是说你告诉我方案的名称就可以了，然后由工厂代替你去构建具体方案（工厂代替你去买火车票）。

上面的例子里面client代码：
$person = new PersonContext(new TrainStrategy());
$person->travel();
我们看到客户需要自己去创建具体旅行（new TrainStrategy()）实例。传递的是具体实例。
而工厂模式你只要告诉哪种旅行就可以了，不是传递一个具体实例，而是一个标识（旅行方案标识）。

10.总结与分析

1）策略模式是一个比较容易理解和使用的设计模式，策略模式是对算法的封装，它把算法的责任和算法本身分割开，委派给不同的对象管理。策略模式通常把一个系列的算法封装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是“准备一组算法，并将每一个算法封装起来，使得它们可以互换”。
2）在策略模式中，应当由客户端自己决定在什么情况下使用什么具体策略角色。2）
3）策略模式仅仅封装算法，提供新算法插入到已有系统中，以及老算法从系统中“退休”的方便，策略模式并不决定在何时使用何种算法，算法的选择由客户端来决定。这在一定程度上提高了系统的灵活性，但是客户端需要理解所有具体策略类之间的区别，以便选择合适的算法，这也是策略模式的缺点之一，在一定程度上增加了客户端的使用难度。

原文地址：http://blog.csdn.net/hguisu/ar ... 8249/ 查看全部

<?php  

/** 

* 策略模式 

* 定义一系列的算法,把每一个算法封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化 

* 

*/   

  

  

/** 

* 出行旅游 

* 

*  

*/  

interface TravelStrategy{  

    public function travelAlgorithm();  

}   

  

  

/** 

 * 具体策略类(ConcreteStrategy)1：乘坐飞机 

 */  

class AirPlanelStrategy implements TravelStrategy {  

    public function travelAlgorithm(){  

        echo "travel by AirPlain", "<BR>\r\n";   

    }  

}   

  

  

/** 

 * 具体策略类(ConcreteStrategy)2：乘坐火车 

 */  

class TrainStrategy implements TravelStrategy {  

    public function travelAlgorithm(){  

        echo "travel by Train", "<BR>\r\n";   

    }  

}   

  

/** 

 * 具体策略类(ConcreteStrategy)3：骑自行车 

 */  

class BicycleStrategy implements TravelStrategy {  

    public function travelAlgorithm(){  

        echo "travel by Bicycle", "<BR>\r\n";   

    }  

}   

  

  

  

/** 

 *  

 * 环境类(Context):用一个ConcreteStrategy对象来配置。维护一个对Strategy对象的引用。可定义一个接口来让Strategy访问它的数据。 

 * 算法解决类，以提供客户选择使用何种解决方案： 

 */  

class PersonContext{  

    private $_strategy = null;  

  

    public function __construct(TravelStrategy $travel){  

        $this->_strategy = $travel;  

    }  

    /** 

    * 旅行 

    */  

    public function setTravelStrategy(TravelStrategy $travel){  

        $this->_strategy = $travel;  

    }  

    /** 

    * 旅行 

    */  

    public function travel(){  

        return $this->_strategy ->travelAlgorithm();  

    }  

}   

  

// 乘坐火车旅行  

$person = new PersonContext(new TrainStrategy());  

$person->travel();  

  

// 改骑自行车  

$person->setTravelStrategy(new BicycleStrategy());  

$person->travel();  

  

?>   

复杂的软件必须有清晰合理的架构，否则无法开发和维护。

MVC（Model-View-Controller）是最常见的软件架构之一，业界有着广泛应用。它本身很容易理解，但是要讲清楚，它与衍生的 MVP 和 MVVM 架构的区别就不容易了。
 
一、MVC
 
MVC模式的意思是，软件可以分成三个部分。






视图（View）：用户界面。
控制器（Controller）：业务逻辑
模型（Model）：数据保存

各部分之间的通信方式如下。






View 传送指令到 Controller
Controller 完成业务逻辑后，要求 Model 改变状态
Model 将新的数据发送到 View，用户得到反馈

所有通信都是单向的。
 
 
二、互动模式
 
接受用户指令时，MVC 可以分成两种方式。一种是通过 View 接受指令，传递给 Controller。






另一种是直接通过controller接受指令。
 






三、实例：Backbone​
 
实际项目往往采用更灵活的方式，以 Backbone.js 为例。
 






1. 用户可以向 View 发送指令（DOM 事件），再由 View 直接要求 Model 改变状态。

2. 用户也可以直接向 Controller 发送指令（改变 URL 触发 hashChange 事件），再由 Controller 发送给 View。

3. Controller 非常薄，只起到路由的作用，而 View 非常厚，业务逻辑都部署在 View。所以，Backbone 索性取消了 Controller，只保留一个 Router（路由器） 。

 四、MVP
 
MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。






1. 各部分之间的通信，都是双向的。

2. View 与 Model 不发生联系，都通过 Presenter 传递。

3. View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

 五、MVVM
 
MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。
 





 
唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。Angular 和 Ember 都采用这种模式。 查看全部