MVC or just Model-View recommended for QML-Qt
-
I've written codes in Qml with Qt/C++ and am continuing doing so.
In my previous codes I just had a Model-View architecture with Model in C++ which would either be QObject derivatives or QAbstractListModel derivatives etc. Every state was maintained in those classes itself as Q_PROPERTY which the QML (the view) would read and update itself (eg., if button needed to be enabled disabled etc). Now it is being said that Proper MVC's should have like group of controllers each managing many views and connecting to some models etc and a master-controller which glues these stuffs together. When I use controller I find everything being redundant - all the states I was maintaining in Model previously have now to be maintained in controllers and Model now emits signals which are caught by controller and sent again to view (also in other direction). So it looks like needless redundancy. In you experience is there really a need for explicit controllers when using QML - Qt/c++ combo ? I don't quite understand what I would miss if i do not use controllers. -
I'm not an expert in MVC(Modev-View-Controller) and its derivatives like MVP(Model-View-Presenter), MVVM(Modev-View-ViewModel), MVD(Model-View-Delegate) (which is used in Qt).
Just a comment on this statement.
[quote]In my previous codes I just had a Model-View architecture with Model in C++ which would either be QObject derivatives or QAbstractListModel derivatives etc. Every state was maintained in those classes itself as Q_PROPERTY which the QML (the view) would read and update itself (eg., if button needed to be enabled disabled etc). [/quote]
It sounds like you keep business data and presentation data (button visibility, etc) in the same object. What if you will need to create another view for the same business data. You will have to add a presentation data and logic for the second view into the same model.
I would put business data into separate class and will create a class with a presentation data for each new view.
This presentation class will have the Q_PROPERTY's to access from QML and will now how to retrieve data from business data class. -
Fair point. So do you reckon that that's what a controller should be - a state maintainer + to/fro bridge between model and view ? The latter part bugs me and seems like needless indirection which prompted me to do what i mentioned,
-
[quote author="ustulation" date="1419442230"]So do you reckon that that's what a controller should be - a state maintainer + to/fro bridge between model and view ?[/quote]
Yes, I think we can call it a controller. Another name would be a presenter. Or maybe a delegate. But I'm not sure about delegate.[quote author="ustulation" date="1419442230"]The latter part bugs me and seems like needless indirection which prompted me to do what i mentioned,[/quote]
This indirection helps to split one layer from another.
I think the rule here is "add as many indirection as necessary but not more". -
QML is REALLY powerful for development and it makes sense to rely on it for more than just view code.
You can have logic / model / view code in both QML or C++ code, so a clean architecture is very important!
We've prepared a guide how to best structure QML-driven apps, and when to use C++ vs. QML. See the full guide here: https://v-play.net/apps/avoid-cpp-models-qt
Best,
GTDev