全栈设计模式套餐MVVM, RESTful, MVC的历史探索

众所周知, 软件开发时遵照一个规范的设计模式很是重要, 学习行业内主流的design pattern每每可以为你节省大部分时间.

根据我2年的全栈经验, 在Web应用程序领域最流行的, 而且若干年内不会过期的设计模式套餐分别是: 前端的MVVM, 后端的MVC, 以及中间的restful api设计模式, 这三个设计模式的搭配很是完美, 以致于几乎全部的互联网服务都效仿这个标准来开发应用.

可是很遗憾, 不少新人仍是喜欢培养本身的编程风格, 甚至认为本身的开放方式比主流的设计模式在某些方面更优秀, 若是有这个思想说明你的确是个聪明,积极的程序员, 但必定没有太多经验, 由于dalao们开发任何一款app都会遵循相关的设计模式, 宁愿放弃也许存在的更好的'冷门模式',也要从众, 这就说明主流模式的存在必定有他们存在的意义.

 

学习设计模式的好处

摘自书上:

帮助咱们将应用组织成容易了解，容易维护，具备弹性的架构，创建可维护的系统，要诀在于随时想到系统之后可能须要的变化以及应付变化的原则。

一、设计模式能让程序员之间更有默契

程序员A：我这个项目用了XXX设计模式

程序员B：那我大体了解你程序的设计思路了, 我知道该怎么阅读你的代码了!

二、易维护, 易扩展

PM：今天客户有这样一个新需求…你看能不能实现[惧怕]

程序员：明白了，还好我使用了XXX设计模式，因此改起来很快

三、设计模式让你快速的开发一个项目, 减小思考的时间

程序员A：你怎么想到要这样去构建你的代码?

程序员B：在我学习了XXX设计模式以后，对领导的需求马上就能抽象成相关的架构, 很是舒服!!

 

因此说, 遵照设计模式是为了应对新的变化和新的'人'

全栈设计模式的历史

数据显示分离时代

如今后端MVC太经典了, 但mvc是从前端的'数据显示分离'进化而来的, 

原来旧PC时代, 大概上个世纪的'数据显示分离'设计模式只是适用于单机的app, 不参与任何网络服务, 好比小游戏, 这时候将数据和显示分红2层很是完美, 可是后来随着本地数据库和其余永久性存储的解决方案出现之后, 2层分离明显不够用了, 因而就有了MVC的雏形...

前端mvc时代

这时候mvc还未发展成熟, 其中的中间层'controller'仅仅是起到一个过滤做用, 同时为了知足多人合做开发应用的需求, 也使得这个'伪mvc'的3层结构变得异常多样化, 这个特殊时代前端的设计模式是五花八门的, 很是混乱, 惋惜我也没经历过那个年代(大概在web1.0早期), 但能够确定正是那时候最先的一批web开发者的努力探索, 才有咱们今天优秀的设计模式可参考.

 

先后端分离时代

后来慢慢的单机app再也不流行, 取而代之的是网络app, 也就是web应用, 这时候mvc的设计思想正式被规范化了, 这里规定了, 中间层做为主线控制逻辑, 数据层和显示层做为辅助模块而存在, 这时候架构师思考应用的'主线剧情'始终绑定在中间的'逻辑控制层'

这个时代仍然是过渡时代, 由于分离, 造成了前端mvc+后端mvc的混沌局面, 这时候产生了一个核心问题: "业务的重心放在前端仍是后端?"

RESTful API的诞生 --- 后端已成熟

restful api的诞生具备划时代的意义, 由于它定义了全部网际服务的接口规范(不是标准), 而且将全部服务器提供的服务都概括为'增删改查'.

REST全称是Representational State Transfer，中文意思是表述性状态转移。 它首次出如今2000年Roy Fielding(HTTP规范的主要编写者之一)的博士论文中。 他在论文中提到："我这篇文章的写做目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，获得一个功能强、性能好、适宜通讯的架构。" 若是一个架构符合REST的约束条件和原则，咱们就称它为RESTful架构。

RESTful设计模式真正成熟是在2009年左右, 移动互联网全面来袭的时候, 彻底遵照了原web2.0时代还没有饱和的REST(由于还有许多历史遗留的过期模式), 几乎全部手机app无一例外的使用了Http(s)来实现本身的业务, 甚至不少直接照搬了html那一套框架, 移动互联网来的太猛烈, 没有时间所有定制本身的技术和设计模式, 因此http+rest此时成为垄断性的行业规范.

REST是创建在HTTP之上的哲学, 固然也完美遵循了http的request和response一一对应的经典模式, 能够说, REST是HTTP的深入总结, HTTP是REST的完美实现.

除此以外, restful和mvc也完美的结合, 成为后端的开发标准, restful主要体如今后端mvc的逻辑控制层, 进行数据转发接收以及用户验证, 当今不少web框架都支持restful+mvc,好比Express.js, .Net, Apache

推荐ruanyif的博客, 里面详细介绍了rest的思想:

http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html

MVVM的诞生 --- 前端已成熟

移动互联网以后,后端已经稳定, 前端也在慢慢发生着变革, 前端由传统的mvc渐渐演变成MVVM:

什么是MVVM？MVVM是Model-View-ViewModel的缩写。mvvm由微软提出, 它的诞生是为了解决前端的问题: 前面说先后端分离时代的新问题'业务重心放前端仍是后端'后来的趋势是, 愈来愈多的计算任务放在了前端, 只将和安全有关的任务放在后端作, 这时候前端人员的工做量异常的巨大, 因而你们但愿可以将'数据绑定''这样的体力劳动让系统本身负责, 因而就有了mvvm, mvvm的核心就是数据绑定, 换句话说是让数据与显示完彻底全分离.

基于这样的新趋势, 各路大仙纷纷推出了本身的mvvm框架, 好比浏览器领域的vue,react和angular, 可是很遗憾的是dom自己还不能完美支持mvvm, 目前想要使用只能借助框架, 另外一个后起之秀Qt则原生支持了数据绑定, 相信浏览器也会慢慢的支持..

 

平行层的多元化

目前为止, 大势已定: 前端mvvm, 后端mvc, 中间restful成为每家每户的必备工具, 可是这个大致架构下的内部架构是能够根据不一样的业务而定制的, 所以出现了不少'平行层', 好比和数据访问层平行的模型层, 和入口文件平行的配置文件, 还有和其余辅助类平行的工具层, 所以真正项目中的层次是不止3层的, 固然这就彻底没有规范了, 仍是根据实际状况而定吧.

模块化编程统一每一层的细节

最后我想谈谈, 在代码规范上, 咱们主要遵循一种叫模块化编程的设计规范, 在JavaScript中体现为函数式编程风格, 模块化的本质上虽然是'分离', 但效果上却把零碎的逻辑整合到一块儿, 更利于开发者思考.

UI设计模式

为了让用户更好的理解UI的功能, 在UI设计上最好也遵照主流的设计模式好比alphabet的material和microsoft的universal等.

项目构建模式

随着项目构建发布的流程日趋复杂, 在构建(building)领域也正在造成统一的规范, 固然如今8102年尚未造成...那就不谈了吧, 但要意识到这个趋势

 

 

设计模式的"隐患"

并非说遵照主流设计模式就百利而无一害, 设计模式都是有代价的, 咱们了解一下就好:

1. 高可扩展性会牺牲高内聚低耦合度

设计模式几乎都体现了高可扩展性, 觉得能够知足性的需求, 可是仔细想一想可扩展意味着接口预留丰富, 层次划分多级, 整个系统的体积也会很大, 天然会致使内聚性的下降, 性能的衰减, 固然不少状况下这是不可避免的, 咱们仍然选择了牺牲硬件成原本保证逻辑上的安全, 毕竟硬件资源愈来愈廉价.

 

2. 让你变得更懒惰:)

项目一上手就急着找相关的设计模式, 必定程度上减小了本身思考的时间, 同时, 设计模式在实际状况上的实现也有无数种方案, 若是新人一开始直接照搬别人的模式拒绝本身思考, 甚至不理解整个模式的工做流程, 这该是一件多么可怕的事情.

 

3. 选择错误的代价

设计模式虽然让你的项目更易修改, 但若是你想更换整个设计模式就是件很痛苦的事情了, 若是你发现整个系统从一开始就设计失误, 不只往后再难微调, 还会形成极大的安全隐患. 因此个人建议是, 若是你是新手, 或者你对一个全新的设计模式0了解, 那就不要急着上手, 学会先思考, 针对目前的项目设计一个本身的设计模式, 思考的同事考虑扩展性, 可读性, 功能性, 性能等因素, 以后再拿这个本身的设计模式到互联网上寻找相似的模式, 或者像前辈请教, 若是发现了一个形态不一样但本质同样的设计思想或者看到了更好的解决方案, 那就说明你成功了.