MVC分层架构和Flux架构
1. MVC架构
2. Flux架构
Flux定义:用于构建用户界面的应用程序体系结构。
用过redux的同学们应该对这个图有比较深刻的理解,因为redux就是flux架构的实现。
3. MVC架构和Flux架构对比
干看上面的两个图,其实我觉得对比不出来什么。
于是我有了一个很诡异的想法,如下图:
Flux架构相对于MVC架构少了两条比较重要的线:
① 视图层 指向 模型层 的那条线
② 控制层 指向 视图层 的那条线
然后从这两条线展开去思考我们的问题:
Flux架构相比于MVC架构有了什么改变,进一步思考:Flux架构的这个改变优化了哪些问题?
(1)视图层 指向 模型层 的那条线没了,也就是说:用户在客户端的操作不能直接影响模型层不能直接改变数据。而是要通过action去影响Dispatcher,从而去影响Store(然后改变数据)。
(2)控制层 指向 视图层 的那条线没了,说明:也就是说业务逻辑不能直接去影响客户端的显示,而是要通过改变数据模型,改变后的数据再显示在客户端的界面上。
就这么一分析,Flux架构给我的感觉像很克制、很谨慎的成熟大叔。
然后,我们结合协同类项目的特点去分析MVC架构:
(1)双向绑定
MVC架构不同于Flux架构有双向绑定机制:
如图所示,当A中的数据被改变的时候,B中的数据也会被改变。这种情况是个人都能感觉到在做协同类项目的过程中绝对是个 致命伤 ,上一篇刚刚提到了CRDT。
回忆一下MVC的各个层的职责:
Model(逻辑): ① 管理业务逻辑 ② 管理数据库逻辑
Model应该就像一个肥胖的大Boss
Controller(动作):① 响应用户请求 ② 管理Model(准备什么“数据”来展示) ③ View中的通信(决定用什么视图)
Controller像瘦瘦的搬运工
View(视图): ① 渲染页面
以上这种灵活但错综复杂的分工也不太适合做协作类的工具。
那么,我们到底想要什么呢?
1. 首先最好是一个单向数据流,做到View、Model、Controller分离,职能分工明确。
2. 然后如果是多人协作,为了防止冲突,最好有个执行的先后顺序,然后有相应的算法,序列化也有助于做redo、undo、history等功能。
3. 具有灵活的插件机制
4. 待补充...
本文参考:
1. 前端架构101(四):MVC的不足与Flux的崛起
https://juejin.cn/post/6844904184655921159