javaScript设计模式简记-架构型设计模式

Posted 2020-12-08 LeoX的爬坑笔记

1.同步模块模式

模块化:将复杂的系统分解成高内聚、低耦合的模块，使系统开发变得可控、可维护、可拓展，提高模块的复用率。

同步模块模式一SMD (Synchronous Module Definition):请求发出后，无论模块是否存在，立即执行后续的逻辑，实现模块开发中对模块的立即引用。

模块化开发的思想是将复杂的系统分解成高内聚低耦合的模块，然后每位工程师独立地去开发自己的模块实现复杂的系统可控、可维护、可拓展，当然模块间也可相互调用，来提升模块的功能复用。

实现模块化开发，首先要有一个模块管理器，它管理着模块的创建与调度。对于模块的调用分为两类，第一-类同步模块调度的实现比较简单，不需要考虑模块间的异步加载。第二类异步模块调度的实现就比较繁琐。它可实现对模块的加载调度。

模块化开发即是以分而治之的思想，实现对复杂系统的分解，使系统随着其功能的增加而变得可控、可拓展、可维护。这就要求我们对模块细化。随着系统功能的增加模块的数量也随之增加。模块开发的成本随之减少，但是模块的接口数量却随之增加，接口的使用成本和开发与维护成本也随之增加，所以合理的模块分割显得尤为重要。模块化开发是一种对系统的分解，但使用时又像是以组合模式对模块的组合。因此这也使得系统中的问题一-般出现在局部，使得开发人员处理相应模块即可，而不用顾虑整个系统。因此相对于整个复杂的系统，对于局部模块的改造、优化甚至替换所需成本要小得多。组合的灵活性也使得我们可以实现更复杂、多样化的功能。在Web前端，实现的模块化开发往往创建了大量的闭包，这会在内存中占用大量的资源得不到释放，这是一种资源的浪费，但相对于解决的问题来说，这种开销是值得的。同步模块模式是模块化开发的一一种最简单的形式，这种模式使得依赖的模块无论加载，无论有无，模块创建即执行，这就要求依赖的模块必然是创建过的。同步模块模式无法处理异步加载的模块，因此浏览器端异步加载文件的环境模式限制了同步模块模式的应用。不过对于服务器端如nodejs等，他们的文件都存储在本地，因此同步模块模式更适用。

 

2.异步模块模式

异步模块模式一AMD (Asynchronous Module Definition):请求发出后，继续其他业务逻辑，直到模块加载完成执行后续的逻辑，实现模块开发中对模块加载完成后的引用。

模块化开发不仅解决了系统的复杂性问题，而且减少了多人开发中变量、方法名被覆盖的问题。通过其强大的命名空间管理，使模块的结构更合理。通过对模块的引用，提高了模块代码复用率。异步模块模式在此基础上增加了模块依赖，使开发者不必担心某些方法尚未加载或未加载完全造成的无法使用问题。异步加载部分功能也可将更多首屏不必要的功能剥离出去，减少首屏加载成本。

 

3.Widget模式

Widget: ( Web Widget指的是一块可以在任意页面中执行的代码块) Widget模式是指借用Web Widget思想将页面分解成部件，针对部件开发，最终组合成完整的页面。

Widget架构模式是页面开发模块化，不仅仅是页面功能，甚至页面的每个组件模块都可以独立地开发，这更适合团队中多人开发。并且降低相互之间因功能或者视图创建的耦合影响概率。一个组件即是一个文件，也让我们更好地管理一个页面，当然组件的多样化也会组建一个更丰富的页面，同样也会让组件的复用率提高，这是很有必要的。这也是组件开发的价值所在。由于在前端开发中很少直接操作数据库(有时会操作一些前端数据库,如localstorage等), 因此同步数据(页面加载时获得)与异步数据(ajax 等异步请求获取)是组件数据的主要来源，如果页面交互复杂，异步数据是主要来源。而数据的操作主要由服务器端负责，因此组件获取到的数据通常是可以满足前端需求格式的，除非服务器端对请求接口的重构需要前端适配新数据，否则通常获取的数据都能满足前端需求。

 

4.MVC模式

MVC即模型(model) 一视图(view) 一控制器(controller)，用一种将业务逻辑、数据、视图分离的方式组织架构代码。

// 页面加载后创建 MVC对象
$(function() {
  //初始化MVC对象
  var MVC = MVC || {};
  //初始化MVC数据模型层
  MVC.model = function(){}();
  //初始化MVC视图层
  MVC.view = function(){}();
  //初始化MVC控制器层
  MVC.ctrl = function()(}();
}) ;

MVC架构模式很好地解决了页面中数据层、视图层、业务逻辑层(控制器)之间的耦合关系，使它们得到显性的区分，这也使得层次之间的耦合度降低。我们在开发中可以不用顾忌所有需求而专注于某一层次开发，降低了开发与维护成本，提升了开发效率。如果页面系统足够复杂，某些视图要共享同-组数据，或者某些需求的实现引用类似视图，此时MVC模式便可提高某些视图与数据的复用率。因此对于大型页面系统的开发，三个层次各司其职。每一层次专注于自己的事情，有利于工程化、模式化开发并管理代码;便于大型页面系统的可持续开发与维护;也是降低层次耦合、提升代码复用的良好实践。在复杂组件的开发中，运用MVC思想管理组件内部的层次也是一种不错的选择。

5.MVP模式

MVP即模型(Model) — 视图 (View) 一 管理器(Presenter): View 层不直接引用Model层内的数据，而是通过Presenter 层实现对Model层内的数据访问。即所有层次的交互都发生在Presenter层中。

// MVP模块
~ (function (window) {
// MVP 构造函数
var MVP = function() {};
//数据层
MVP . model = function() {};
// 视图层
MVP.view = function() {};
//管理层
MVP .presenter = function() {};
// MVP入口
MVP.init = function() { }
//暴露MVP对象，这样即可在外部访问MVP
window.MVP = MVP;
}) (window)

MVP与MVC相比最重要的特征就是MVP中将视图层与数据层完全解耦，使得对视图层的修改不会影响到数据层，数据层内的数据改动又不会影响到视图层。因此，我们在管理器中对数据或者视图灵活地调用就可使数据层内的数据与视图层内的视图得到更高效的复用。因此，MVP模式也可以实现一个管理器，可以调用多个数据，或者创建多种视图，而且是不受限制的。因而管理器有更高的操作权限，因此对于业务逻辑与需求的实现只需专注于管理器的开发即可，当然管理器内过多的逻辑也使得其开发与维护成本提高。

6.MVVM模式

MVVM模式，模型(Model) -视图(View) -视图模型(ViewModel):为视图层(View)量身定做一套视图模型(ViewModel)，并在视图模型(ViewModel)中创建属性和方法，为视图层(View) 绑定数据(Model) 并实现交互。

MVVM模式与前面的MVC模式、MVP模式类似，或者说MVVM模式是由这两种模式演变而来的，因此它也主要用来分离视图(View)和数据模型(Model)。 不同的是MVVM模式使视图层更灵活，可以独立于数据模型层、视图模型层而独立修改，自由创建。当然这也使得数据模型层可以独立变化，甚至一个视图模型层可以对应多个视图层或者数据模型层。MVVM模式是对视图模型层的高度抽象，因此当多个视图层对应同一个视图模型层时，也使得视图模型层内的代码逻辑变得高度复用。而这种开发模式最重要的一-个特征恐怕就是视图层的独立开发，这样可以使那些不懂javascript的人，只要了解html内容并按照视图层规范格式创建视图即可完成-一个复杂的页面开发，而让那些开发人员可专注于开发视图模型层里面的业务逻辑了。当然测试问题在MVVM中也变得很容易，只需要针对视图模型层撰写测试代码即可。