在写干货之前，我想先探（qiang）讨（diao）两个问题，模式的局限性？模式有什么用？
最近看到一篇文章对我启示很大，许来西在知乎的回答《哲学和科学有什么关联？》，全篇较长，这里摘录我要引出的一点：
科学作为一种履历主义的认识论，有着履历主义的巨大毛病：它永久不能产生绝瞄准确的真理。这是归纳法的实质决定的。而且值得把稳的是，归纳不具有唯一性。
举一个大略的例子，我们假设一个天下，如下图：
科学家很快有了两种归纳办法：
天下上所有的田鸡都戴眼镜
天下上所有戴眼镜的都是田鸡
在没有更多的信息的时候，我们该当如何选择精确的理论呢？答案是无法选择。
举个模式的例子，Scott Wlaschin 在《Functional Programming Design Patterns》（函数型编程模式）中比拟了常用面向工具模式、原则，在函数型编程措辞里面等价实现：
OOP 和 FP，到底哪种编程范式更加前辈呢？答案同样是无法选择。只能在不同的时候选用不同的假设和不同的理论来阐明问题，许来西的文章讲到科学一定程度上通过放弃一向性换取了实用性，放弃自洽性换取了它洽性。科学追求实用和工具（实用主义和工具主义）。当我看完许来西的文章，欣喜若狂，一贯对编程技能理论的善变和不自洽感到恐怖和厌恶，实在只是履历主义科学发展的一定过程，善变代表更好的理论（更方便）在更换根本理论，代表发达发展。
以是我想引入第一个不雅观点：
模式是一套立足于特定背景，基于共性总结出的方案，它绝不是真理。
理解这些有助于帮助从对模式的盲目崇拜到探究它的实用性和工具性，也便是我要引出的第二个问题：模式有什么用？
不好好写代码看哲学文章不是有时，在文章落笔之前，我有思考过在 JavaScript 这门动态，多范式，单线程，基于事宜I/O的措辞环境下，乃至在当前时期，模式是否还故意义？显然我不是唯一这样想的，还有篇深度好文《20年前GoF提出的设计模式，对这个时期是否还有辅导意义？》。这篇文章引经据典，摘录了GoF（又称Gang of Four，即Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides）在设计模式一书中不雅观点：
这本书的实际代价大概还值得商榷。毕竟它并没有提出任何前所未有的算法或者编程技能。它也没能给出任何严格的系统设计方法或者新的设计开拓理论——它只是对现有设计成果的一种核阅。大家当然可以将其视为一套不错的教程，但它显然无法为履历丰富的面向工具设计职员带来多少帮助。
换言之，模式显然毫无实际用途。
不仅如此，文章还列举了一度模式滥用导致许多弊端，可谓警钟长鸣。
但是……模式这一称谓仍旧不断涌现，直到本日我们亦在大量利用。为什么？GoF实际早设计模式的书中做出了预言：
“设计模式为设计师们供应一种共通的词汇储备，帮助其沟通、编写文档并探索设计方案。设计模式许可我们立足于高等抽象层面进行磋商，而非设计标注或者编程措辞，这就大大降落了系统繁芜性。设计模式提升了我们设计及与同事进行设计磋商时的切入点层级。”（第389页）
简言之，模式方便了我们的沟通，提升了思考问题的抽象层级。
这个意义非常巨大，想象一下没有 MVC 架构模式，可能所有的 Web 框架一定的会实现一套险些办理同样问题的方案，但是命名和文档却各不一样，当你去看一个新的框架文档的api 接口，从头到尾看完往后才恍然大悟，这不便是之前用的框架里面的 XXX 类似吗，这样的编程天下切实其实地狱。光彩的是，得益于打算机科学家（码农）对问题和方案持续的抽象成模式，使得当前高度繁芜的打算机科学也能得到合理分层和适配，大大简化了学习和沟通的本钱。
为了感谢模式，是时候学习一波了，本文要先容的紧张有三种架构模式：Middleware，MVC，DI。
Middleware 中间件模式
相信做过 Node.js 做事端开拓的同学对这个模式一定不陌生，考虑如下 Web 运用的场景：
在一个大略的 HTTP 要求相应周期里，有如下条件处理，
记录开始韶光
须要验证用户的身份 authentication。
解析cookie 并加载body
根据路由返回不同的业务处理结果
没有命中路由则返回404页面
记录日志
记录统共花费韶光
处理非常并显示页面（开拓环境）
有些处理会根据是否成功决定是否连续后面的粗粒，有些处理会天生额外的数据，还有的哀求拦截某些处理的开始和结束，末了非常处理和记录日志哀求一定被实行。
一样平常的办理方法是用嵌套条件判断结合trycatchfinallyreturn等掌握语句，但是这样的方案会导致代码碎片化和复制粘贴的编码风格，由于掌握流和逻辑耦合到了一起。空想的方案应该如下：
中央化掌握流
解耦处理模块（重用性）
声明式、可配置的做事(配置和代码无关)
这些场景由来已久，良久以前J2EE总结了 Intercepting Filter 模式，有兴趣大家可以看看这篇文(lun)章(wen)，里面由浅入深提到三种方案，个中最低级的方案代码如下：
这个和 express 和 Koa 的中间件模式极其相似，但是由于静态措辞本身一些特色，导致末了形成的企业级代码极其繁琐，并且有许多局限性。最紧张的问题是处理模块之间难以重用和共享数据，由于ServletRequestServletResponse无法动态添加属性。以至于 JavaEE 把这个模式的适用性加了许多限定，包括和核心处理逻辑分开。
在动态措辞的天下里面，我们可以很方便的往req和res里面添加数据（基于约定），由于没有了很多 OOP 天下里面的”束缚“，Node.js 的实现常日更加优雅和通用。
Express 中间件模式
express 实现如今广泛接管的 Middleware 中间件模式。中间件的意思是在要乞降相应中间实行的函数（为了区分另一个中间件），署名如下：
这个模式包含了一套声明式的路由规则，和 middleware 函数上的 next 署名，它们共同构成了全体中间件模式的掌握流，如图：
这个模式的核心构成不是权限，解析等中间件逻辑，而是路由判断，next和中断相应（验证失落败、解析失落败），其作为中间件实行掌握，解耦了详细的处理逻辑，使得更随意马虎写出通用的细粒度的中间件。express 内置的强大的声明式路由，并且路由和 middleware 分离可以说是它最成功的设计之一。
然而在一些轻微繁芜点的业务中，比如一个网站有管理端和用户端，两个审察当于独立的app。express 4.0 供应了一个非常强大的功能 Router。Router 拓展了链式决策变成树形决策，可以让 express 更好的支持大型项目。
Koa 异步中间件模型
Koa 的异步中间件模式-洋葱模型，比较 Express，个中央件函数返回Promise，支持async/await，并且可以轻松实现前置和后置的处理。毫无疑问这个模式更加前辈，一些在 express 里面不好实现的拦截处理逻辑，比如非常处理和统计韶光，在 Koa 里用一个中间件就能搞定。然而遗憾的是 Koa 本身只供应了 Http 模块和洋葱模型的最小封装。
未来我看好 Koa，实在 express 也意识到这点，他们操持在 5.0 版本里添加 Promise 的支持，然而作为一个老牌和完全生态的框架，要战胜的困难远不是技能层面上看似的大略，直到目前仍旧没有看到 5.x 宣告支持Promise， 让我们拭目以待。
MVC 模式
MVC 模式也须要先容吗，我们每天都在聊 MVC，不管前、后端框架，说一句 MVC，对一下眼神，基本确定对方懂你了。
事实是，前端框架已经不适宜用 MVC 谈论，这个模式从1979年提出以来，作为万精油模式，在各个框架和场景中被套用，背负了太多的历史包袱，大家可以看 winter 的文章 谈谈UI架构设计的蜕变。拨乱反正我以为有希望，谈论前端框架大家往后统称 MV 模式就好了，便是模型和视图分离。
我们本日要讲的 MVC 模式是指在做事器上（后端） MVC 模式，它的定义经受了韶光和实践的考验，在许多企业级 Web 框架的实现中高度同等。先列举场景：
如果你的网站只有几个大略的页面，所有逻辑都写在 Controller 里面，是没有问题的。随后网站迅速的增长，你创造，
许多页面里面的视图是同等的，但是背后的数据模型不一致。比如：网站上险些没有一个视图或者组件是独一无二的，表格，下拉框等。
许多页面里面的数据模型是一样的，但是展现的视图不一致。比如：同时支持PC和移动端，国际化本地化。
我们做一个数学模型仿照极度情形，大家很随意马虎能看到问题
假设左边是我们的系统终极的样子，它刚好可以表示成 M（模型）和 V(视图）的内积，我们更方向于右边的表达，由于它更简洁而且没有重复。这里的内积操作大家就可以理解成掌握器，实际上不会如此巧合，但是分离模型和视图帮助我们提高代码复用，降落设计繁芜度的好处是很显然的，一个更通用的表达
模型视图和掌握器之间都是单向链接，以是全体系统的行为非常可控且随意马虎测试，单独把路由分开是想强调 Router 和 Controller 是两个观点，Router 只是一个触发器（或者供应了一种映射关系），在写测试的时候，我们也可以跳开 Router 单独调用 Controller。
看到上面的两种模式，是不是已经开始想，那有没有一个框架同时是 Koa + Router + MVC 呢，推举大家一个非常好用的企业级 Web 框架 ThinkJS 3.0，最新版的 ThinkJS 集成了大量最佳实践和完善的文档，不管是学习或者企业级开拓都非常推举。而且 ThinkJS 同样实现了接下来要讲的模式。
DI 依赖注入模式
还是先说场景，如果做事端须要实现session，前期考虑到本钱和用户量，单台做事器存到文件就够用了。后期如果用户量大的时候，须要横向扩展（Scale-out），就把 session 实现基于中央化的 Redis 做事。
我们系统设计目标是：
不须要修正业务逻辑代码实现更换
不须要关注做事的创建和生命周期
办理这类系统扩展性问题有一个非常著名的设计原则掌握反转（IoC Inversion of control），而依赖注入（DI dependency injection）便是个中的一个实现模式。
DI 的基本思路是这样，首先我们的代码不能依赖详细的做事，须要总结归纳出一套抽象接口，业务实现依赖接口，而做事实现接口，末了通过框架专门卖力创建和供应接口的实例。
这里的 IoC 容器或者说 Ioc 框架，会在启动的时候读取配置文件，并在运行的时候根据须要创建实例供应给利用者，在静态措辞如java，c#须要用到反射等高等语法，而JavaScript本身是动态的，接口基于约定，并且利用的办法也更加灵巧。比如 ThinkJS 3.0 里面的extend和adapter就可以理解成接口和实现，如图：
那之以是称为 extend，是由于框架会直接把接口注入(mixin)到controller或者think工具中。这样的好处是利用起来更方便，缺陷是不同extend须要约定好不能重名。
末了
本文先容的三个架构模式，你会创造险些在所有的Web框架实现都大同小异，这便是模式的好处。模式的意义类似于 IoC，我关注抽象和接口，抹平了详细措辞特性下的细节问题，帮助我们更好的学习，沟通和思考。
编辑：千锋HTML5
作者：蔡斯杰
https://75team.com/post/web-architecture-patterns-javascript
