【辣眼慎入】学习 结合Yjs制作编辑器 有感(二)

865 阅读2分钟

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