DaveR
15th June 2015, 19:26
My colleagues are interested in refactoring a mid-size (15,000 line) application to use a complete separation of Qt from the model. That is to say, the model would not contain any "Q" types at all and would live in a separate directory. A controller would then be used to talk to the view.
We're used this architecture to good effect in the past, for a real-time application. In this case the threading model was more complex (since it was for real-time apps), so it was advantageous to have the underbelly in pure C++.
In the case of our current application however I'm not so sure. It's a single-threaded application and most of the data that would be contained in the "model" is view-related data anyway, such as panel positions and widget sizes.
My question is, how often is a complete separation of model from view an approach that is used in practice for Qt? Is this something you've personally used to good effect?
We're used this architecture to good effect in the past, for a real-time application. In this case the threading model was more complex (since it was for real-time apps), so it was advantageous to have the underbelly in pure C++.
In the case of our current application however I'm not so sure. It's a single-threaded application and most of the data that would be contained in the "model" is view-related data anyway, such as panel positions and widget sizes.
My question is, how often is a complete separation of model from view an approach that is used in practice for Qt? Is this something you've personally used to good effect?