Important: Please read the Qt Code of Conduct -

Flux like architecture with Model/View

  • Hi,

    in Model/View with complex SQL Databases i asked for some advice for my application design and was told to take a look at Flux as possible solution.

    Now that i've read about it and given it some thought I'd like to share my thoughts and get some feedback.

    In my opinion there is only one difference between MVC and Flux: In Flux, controller and model are combined to the store. Everything else is pretty much the same and only differs in details, and many disadvantages mentioned for MVC looks like a bad/inappropriate MVC design to me.

    In MVC the view takes user input, gives it to the controller which changes the model.
    In Flux, the view takes the user input and gives it to the action creator. The created action is given to all stores, which are just controller+model combinations. And the dispatcher is just a connection between action creator and stores.
    There isn't really a difference between those two. MVC neither defines how the view communicates with the controller(s) nor how many models are changed by the controller. Thus, Flux is like a version of MVC where the view (with activation creator as helper) creates something like a change event that allways works on all controllers/models (allowing them to ignore it if needed). So it's just like a good MVC design with advantages in certain situations.

    Qt's Model/View Framework is also just a MVC variation. Although, according to Qt, in Model/View the view is a combination of MVC's view and controller, because they introduced delegates it's pretty much the same since they work like controllers.

    So, after looking at this comparison, the question is how to implement this, using as much existing code as possible. I came up with a rough idea on how to do this using Qt's Model/View Framework and would like to hear some feedback from people with more experience working with architectures like these.

    For user input the views refer to delegates to handle this. Letting them launch a change event would give them the job of the action creator. The part of the delegate that actually changes the model could be moved into a store-wrapper class for the model. This would be very similar to Flux. Using the observer pattern to register delegates and views would allow to easily send those events/actions to all models/stores. And since Qt's Signal/Slot system is an advanced version of the observer pattern this could probably be done with this. Updating the view is already part of the model.

    This approach isn't perfect but from what I know about MVC / Model/View and Flux, this should be an easy way to get some of the advantages of Flux into Model/View with minimal effort.

    [ Moved to 'Brainstorm' -- @Wieland]

Log in to reply