MVC layered architecture and Flux architecture

1. The MVC architecture

2. The Flux architecture

3. Comparison between MVC architecture and Flux architecture

Looking at the above two pictures, I don’t think the comparison is anything.

So I came up with a very weird idea, as shown below:

Flux architecture is missing two important lines compared to MVC architecture:

① The line from the view layer to the model layer

② The line from the control layer to the view layer

Then think about our problem from these two lines:

How does the Flux architecture change compared to the MVC architecture? Consider further: What problems are optimized by this change in the Flux architecture?

(1) The line between the view layer and the model layer is gone, that is to say, the user’s operation on the client side cannot directly affect the model layer and cannot directly change the data. Instead, you influence the Dispatcher via action, which affects the Store (and then changes the data).

(2) The line from the control layer to the view layer is gone, which means that the business logic cannot directly affect the display of the client. Instead, the changed data will be displayed on the interface of the client by changing the data model.

On this analysis, the Flux architecture strikes me as a very restrained and cautious mature uncle.

Then, we analyze the MVC architecture based on the characteristics of collaborative class projects:

(1) Bidirectional binding

MVC architecture has a bidirectional binding mechanism different from Flux architecture:

As shown in the figure, when the data in A is changed, the data in B is also changed. This is a situation that everyone can feel is absolutely fatal in the process of doing collaborative projects. The CRDT was just mentioned in the last article.

Recall the responsibilities of the MVC layers:

Model (logic) : ① Managing business logic ② managing database logic Model should be like a fat Boss Controller: ① Respond to user requests ② manage Model (prepare what "data" to display) ③ Communication in View (decide what View to use) Controller like a skinny porter View (View) : ① Render pagesCopy the code

This flexible but intricate division of labor is also not a good fit for collaborative tools.

So what do we really want?

1. First of all, it is best to have a one-way data flow, with View, Model and Controller separated and clear division of functions. 2. However, if multiple people collaborate, it is best to have an order of execution and an algorithm to prevent collisions. Serialization also helps with redo, undo, history, etc. 3. Flexible plug-in mechanism

4. To be added…

This paper reference: 1. The front-end architecture, 101 (4) : https://juejin.cn/post/6844904184655921159 with the rise of the shortage of the MVC and FluxCopy the code