为什么在web前端很少有人会提到分层架构，例如经典MVC架构，这是因为浏览器诞生之初就只是作为一个后端数据的GUI渲染器。也就是说整体来看，web1.0时代的整个web前端工程就是一个View层，而Model和Controller就是指后端，所以基本无需在web前端工程中去提什么MVC。

然而web生态倒退到明天，浏览器越来越弱小，赋能越来越多，甚至不亚于一个小型操作系统，这时候的Web前端早已不是当初简略的数据渲染器，随着PWA、小程序、快利用的推广，WebAPP曾经和传统的“富客户端”没什么两样了。那么在这种趋势下，如果咱们的Web前端架构还停留在View的时代，那么显然是掉队的。

View是最直观的、最原始的驱动源，解决了所有View的问题也就实现了WebApp的所有性能，前端开发人员的全副工作就是一个又一个的编写Component。正是因为这种以View为外围的架构思维，导致咱们只为解决表层问题而架构，不去思考顶层设计，这也是很多Web前端工程通过几轮迭代和人员转手后，很难持续保护上来的根本原因。

近年来涌现出一些优良的UI渲染框架，比方React/Vue/Anglar，它们很弱小，能够干很多分内和分内的事件。正因为如此，更造成了开发者的惰性，将所有逻辑都间接以最原始的形式写在View中，不论是Mode还是Controller，不论是业务逻辑、还是渲染逻辑、还是存储逻辑、还是通信逻辑、还是路由逻辑...所有各类逻辑叠加各种UI生命周期，全副都耦合在一个Component中。

从视图驱动到畛域驱动

是时候扭转咱们的架构思维，从视图驱动升华到畛域驱动。尽管视图驱动是最直观也是最简略的一种架构模式，然而咱们不仅要解决问题，还要思考如何优雅的解决问题，这也好比是排版和设计的区别吧！

或者说，在我的项目横蛮成长的混沌初期你能够从下往上构建，所建即所得。但到了某个重构的工夫点，你还是得站在顶部进行下层设计。

当然，这里有个默认前提，那就是须要长期保护的中大型项目，小而快的我的项目无需谈各种架构模式...

将UI框架拉下神坛

UI不是工程的全副，UI的指摘只有2个：输出与输入，仅此而已。所以即使React/Vue再弱小，你也该当仅把它们当成一个GUI工具，相似于Java Swing和.Net WPF，而非整个工程React/Vue一把梭。

~~ 敲黑板：UI只是指令的收集者、传播者、反馈者，而不该当成为指令的执行者。

利用的外围是业务逻辑

当初问你一个问题：

如果没有UI，你的利用能够通过命令来驱动吗？

你可能会怼我说，用户怎么可能会通过命令来应用我的利用，没有这样的业务场景，你这个假如是毫无意义的。然而，这种场景或者并不是为用户而设，而是为合作伙伴而设、为测试工具而设、为日志剖析而设、为今后的扩大和生态建设而设...

再问你一个问题：

  • UI说：利用要改版，皮肤、交互、页面组织都要调整，要多久？
  • 产品说：把H5改改，做成小程序、APP吧，要多久？
  • 经理说：React人太难招了，要不咱们换成Vue吧，要多久？
  • Leader说：Vue3进去了，咱们降级为最新版吧，要多久？
  • 架构师说：Svelte快到飞，咱们重构为Svelte吧，要多久？

业务逻辑不变，仅调整UI和其运行平台，问你要多久？这个时候，如果你的全副逻辑都是耦合在某种特定的UI框架中的，那你只能是哀默之心大于死...

UI逻辑与业务逻辑拆散

从晚期的前后端一体化，到前面的前后端逻辑拆散，在到这里我重提UI逻辑与业务逻辑拆散，都只是顺着2件事件在做：让须要内聚的更内聚，让能够解耦的更涣散。

  • 业务逻辑形象，UI逻辑具体：业务逻辑是形象的数据模型，而UI逻辑则是形象事物逐层泛化后的具体表现，它们两个自身就不再同一个Level上。
  • 业务逻辑通用，UI逻辑非凡：UI逻辑通常须要借助于某个具体的UI框架而表白，而UI框架通常都会与运行平台非亲非故，同时也会退出本人的各种各种限度、束缚、约定、魔术办法等。所以形象来说，前者是JS国家的普通话，而后者则是方言。
  • 业务逻辑直观，UI逻辑费解：UI渲染自身就是一件很简单的事件，其间波及到各种组件的各种生命周期、创立、销毁、更新、重绘等等、在加上各种优化伎俩造成的心智累赘。所以你会发现某些业务逻辑放在Redux或是Vuex等纯状态治理框架中，比应用组件外部的Hooks去保护更简略和直观。只管Hooks也能够模仿这些Flux框架，然而不迭前者有条理，比方测试、监控、剖析、回滚一个Action多容易，你测试、监控、剖析、回滚一个Hooks试试...
  • 业务逻辑稳固、UI逻辑多变：UI/UE太理性、太灵便了，带有很强的集体主观色调，常常会被优化、批改、甚至颠覆，不像业务逻辑那么稳固。这也是要将UI逻辑和业务逻辑离开的重要起因，如果你将业务逻辑和UI逻辑写在一起，你原本稳固的代码将受到不稳固代码的重大骚挠。

铁打的MV流水的C

当初提MVC是不是过期了？非也，MVC是其实一种最简略的哲学思想，Model代表形象事物，View代表具体事物，而Controller则是代表如何在形象事物和具体事物之间泛化。所以MVC是一种思维，而不是特指某种框架，过期的只会是框架，而非思维。

近年来各种演变如：MVP、MVVM、MVI等等，其实都是在围绕C做文章，最终的目标无非就是更好的隔离M和V，也就是千方百计拆散UI逻辑和业务逻辑。

Flux架构其实也是一种MVC，而Redux/Vuex/Pinia、以及自己的框架Elux，都能够看作它的变种。上面咱们就看看如何利用Flux架构来拆散UI逻辑与业务逻辑：

从State到Model

MVVM利用中充斥着状态，有的用来形容Component的外部情况，它与Component唇齿相依，追随Component诞生和销毁，这就是咱们常说的ComponentState。\
还有一些状态，用来形容业务状态，与具体哪个Component没有间接关系，不存在复用与销毁，咱们能够称它为Model。

  • ComponentState 是UI逻辑，该当封装在Component外面，外界也无需晓得。
  • Model 是业务逻辑，反映整个APP的情况，与Component无关，该当由Flux框架来对立治理。

从Event到Action

用户通过UI界面产生的人机交互事件，咱们习惯叫"Event事件"，而"Event事件"背地的业务目标咱们能够叫"Action动作"，它们一个是因一个是果，一个是表一个本。

  • 解决 Event 的 Handler 是UI逻辑，该当写在UI组件中
  • 解决 Action 的 Handler 是业务逻辑，该当写在Controller外面

举个具体的例子吧："SubmitLoginForm｜提交登录表单"，通常要实现如下逻辑：

  1. 验证输出是否无效
  2. 验证以后用户是否曾经登录
  3. 申请后端API，并期待返回
  4. 如果胜利，保留用户信息，并跳回原页面
  5. 如果失败，提醒谬误，并留在原地

这是一个业务动作，因为它能够不依赖哪个具体UI而运行，用户可能通过“onClick事件”点击登录按钮来触发，也可能通过“onKeyPress”按下回车键来触发，甚至你能够间接让用户通过“Login命令”来触发。

所以“onSubmitLoginForm()”该当写在Controller而非UI组件中。\
UI组件中只有"onLoginButtonClick()"或"onEnterKeyPress()"，而它们往往也就一句话，就是Dispatch一个Action来触发Controller中的“onSubmitLoginForm()”

将业务逻辑移出UI组件，这样UI层就变薄了，回归到了它的实质：只负责收集业务动作，不负责解决它。

改进Flux框架

传统的Flux框架也有痛点：

  • 全局中心化治理导致逻辑过于集中；
  • 单实例、不销毁容易造成信息累积爆炸；
  • DispatchAction机制过于简略，不适宜解决前因后果的长流程业务。

Elux正是针对以上痛点进行了改进：

  • 尽管保持全局中心化治理，但Elux提出“微模块”的概念，将利用拆分成独立自治的一个个“微模块”，每个微模块仅解决本人畛域内的事件。
  • 不再单实例，每次路由变动都会产生一个新的空白Store，而后从新筛选有用的状态挂载，相似一种垃圾回收机制。
  • 提出了ActionBus的概念，让Action作为Model中的事件来播送。
  • 让Action的解决链条具备“协程”机制，更好的协同各业务动作之间的关联。

Elux践行的分层而治

正是因为遵循了轻UI、重Model的设计思维，让Elux能够挂接React/Vue等各种不同的UI框架，它们曾经变得没那么重要了。

正式因为拆散了UI逻辑和业务逻辑，让Elux能够用一种工程模式开发Web(浏览器)、Micro(微前端)、SSR(服务器渲染)、MP(小程序)、APP(手机利用)。

此致！欢送交换：https://eluxjs.com

最初也想跟大家交换一下前端“微模块”的话题：从"微前端"到“微模块”