前言

设计模式，想必都不会陌生，通俗地讲，它是对软件开发过程中反复出现的某类问题的通用解决方案，帮你写出可扩展、可读、可维护的高质量代码。可以提高自己的代码质量，并为以后开发中遇到的问题提供更多的解决思路。

MVC

MVC是一种经典的设计模式，广泛应用于前端框架中。它将应用程序分为三个部分：Model（数据层）、View（视图层）和Controller（控制层）。

Model：负责处理数据和业务逻辑。它代表应用程序的数据结构，可以是本地数据、从后端获取的数据或者其他来源的数据。
View：负责展示数据，通常是用户界面。它从Model中获取数据并将其展示给用户。
Controller：负责处理用户交互，并更新Model和View。它接收用户输入，然后根据输入更新数据和视图。

MVVM

MVVM将视图（View）、数据（Model）和逻辑（ViewModel）分离开来，以达到解耦和方便维护的目的。MVVM即Model-View-ViewModel，是基于MVC和MVP演变而来的设计模式。MVVM采用双向绑定机制，能够使得数据在视图和数据模型之间自动同步，进一步简化了代码的开发和维护。 MVVM的优点：

MVVM 的出现促进了 GUI 前端开发与后端业务逻辑的分离，极大地提高了前端开发效率。
MVVM用接口实现了前后端数据的通信，这样可以使前后端之间的业务逻辑没有什么关系。
MVVM在感觉上要比mvc模式前后端要分的更开

MVVM代码实例：

<div id="app">
    <p>{{message}}</p>
    <button v-on:click="showMessage()">Click me</button>
</div>

var app = new Vue({
    el: '#app',
    data: {     // 用于描述视图状态（有基于 Model 层数据定义的，也有纯前端定义）
        message: 'Hello Vue!',  // 纯前端定义
        server: {}, // 存放基于 Model 层数据的二次封装数据
    },
    methods: {  // 用于描述视图行为（完全前端定义）
        showMessage(){
            let vm = this;
            alert(vm.message);
        }
    },
    created(){
        let vm = this;

        // Ajax 获取 Model 层的数据
        ajax({
            url: '/your/server/data/api',
            success(res){
                // TODO 对获取到的 Model 数据进行转换处理，做二次封装
                vm.server = res;
            }
        });
    }
})

{
    "url": "/your/server/data/api",
    "res": {
        "success": true,
        "name": "IoveC",
        "domain": "www.cnblogs.com"
    }
}

Flux

Flux通过利用一个单向的数据流补充了React的组合视图组件，这更是一种模式而非正式框架，你能够无需许多新代码情况下立即开始使用Flux。

　　Flux应用有三个主要部分：Dispatcher调度、存储Store和视图View(React 组件)，这些不应该和MVC:Model-View-Controll(模型-视图-控制器)混淆，控制器在Flux应用中是存在的，但是他们是controller-view(控制器-视图)，视图通常在一个结构顶部，而这种结构是用来从存储stroe获得数据，然后将数据传递到自己的子结构们，此外，Action创建者-Dispatcher的帮助类的方法 -用于支持一个语义API，这个API是描述应用程序中所有变化的可能，通常可将它们看成是Flux更新循环的第四部分。

FLUX的不足：

冗余代码太多
在每个应用中东需要手动创建一个dispatcher的实例
在一个应用中含有多个store。

单例模式

单例模式，也叫单子模式，属于创建型模式的一种。在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象，这样有利于我们协调系统整体的行为。比如在某个服务器程序中，该服务器的配置信息存放在一个文件中，这些配置数据由一个单例对象统一读取，然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。单例模式的优缺点：

优点：

你可以保证一个类只有一个实例。
你获得了一个指向该实例的全局访问节点。
仅在首次请求单例对象时对其进行初始化。

缺点：

违反了单一职责原则。该模式同时解决了两个问题。
单例模式可能掩盖不良设计，比如程序各组件之间相互了解过多等。
单例的客户端代码单元测试可能会比较困难，因为许多测试框架以基于继承的方式创建模拟对象。由于单例类的构造函数是私有的，而且绝大部分语言无法重写静态方法，所以你需要想出仔细考虑模拟单例的方法。要么干脆不编写测试代码，或者不使用单例模式。

观察者模式

观察者模式定义了对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都将得到通知，并自动更新。观察者模式属于行为型模式。它定义一种“一对多”的关系；这里的“一”我们称为目标对象（Subject），它有增加/删除/通知等方法，而“多”则称为观察者对象（Observer），它可以接收目标对象（Subject）的状态改变并进行处理；目标对象可以添加一系列的观察者对象，当目标对象的状态发生改变时，就会通知所有的观察者对象。

详解前端框架中的设计模式|青训营

前言

MVC

MVVM

Flux

单例模式

观察者模式