众所周知, 软件开发时遵守一个规范的设计模式非常重要, 学习行业内主流的design pattern往往能够为你节省大部分时间.

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

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

 

学习设计模式的好处

摘自书上:

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

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

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

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

2、易维护, 易扩展

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

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

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

程序员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了解, 那就不要急着上手, 学会先思考, 针对目前的项目设计一个自己的设计模式, 思考的同事考虑扩展性, 可读性, 功能性, 性能等因素, 之后再拿这个自己的设计模式到互联网上寻找类似的模式, 或者像前辈请教, 如果发现了一个形态不同但本质一样的设计思想或者看到了更好的解决方案, 那就说明你成功了.