A professional opinion on Qt's Model/View paradigm
Hi all,
I would like an opinion from someone who has used Qt's Model/View to design medium to large application scale applications?
I ask this as while I am quite familiar with MVC but I have not encountered or tried to use a Model/View paradigm and would like to know how it holds up in a commercial application.
Some of my thoughts are:
- Does the combining of the view and the controller work in the end?
- Without Controllers how have others developing large scale applications separated and managed the application, management and storage control with Qt's MV?
- Conceptually could the Qt Delegate between the View and Model be used or though of as a Mediator?
- Can the Qt Delegate connect to multiple GUI components in the View?
- Can Qt's Views contain more that one GUI element at once.
- Can Qt's Delegate connect multiple GUI elements in a view and to multiple Models?
- I any, what issues have other programmers here had with the MV paradigm?
I am tempted to add my own Singleton Controllers in with the Qt MV concept. Has anyone here done this with good results?
Re: A professional opinion on Qt's Model/View paradigm
Quote:
Originally Posted by
jerome
- Does the combining of the view and the controller work in the end?
It's a big simplification to say that the view and controller are combined. The job of the controller is shared by the view, the delegate and the event loop. Yes, it works fine.
Quote:
- Without Controllers how have others developing large scale applications separated and managed the application, management and storage control with Qt's MV?
I think I might not understand your question however I will try to guess what you mean. Storage is controlled solely by the model or an external component outside the model-view framework (the model serves practically only as an interface to data). Application is driven by the event loop, the cooperation between the model and the view is driven by signals and slots.
Quote:
- Conceptually could the Qt Delegate between the View and Model be used or though of as a Mediator?
No. It's rather a kind of handyman who's called to do work on behalf of the model or the view. It can easily be replaced with a different implementation which allows to drastically change the overall looks or behaviour of the system with just a few lines of code.
Quote:
- Can the Qt Delegate connect to multiple GUI components in the View?
I don't understand the question. The view is usually a single component.
Quote:
- Can Qt's Views contain more that one GUI element at once.
Theoretically yes however I don't think I have seen a view which was a composition of some other widgets.
Quote:
- Can Qt's Delegate connect multiple GUI elements in a view and to multiple Models?
As I've already written, the delegate doesn't "connect" anything, it's not a mediator --- signals and slots are used for that. However a single delegate can usually be shared by multiple models and views.
Quote:
- I any, what issues have other programmers here had with the MV paradigm?
It becomes complicated once you want to do wacky things with it. The separation between the logic and the presentation is a bit flawed as things like the font or colours are (or rather can be) stored within the model. It's not a big deal and there are ways of fixing it but some see it as a design glitch. The last thing is that the view API is somewhat limited -- each item is assumed to be a static rectangular element which doesn't fit well the concept of those new funky shiny fluid user interfaces like on smartphones.
Quote:
I am tempted to add my own Singleton Controllers in with the Qt MV concept. Has anyone here done this with good results?
I don't see any benefits of that with the current architecture (but maybe I just don't see the big picture of what you would like to do). If you want, you can implement a complete MVC scheme from scratch instead.
Re: A professional opinion on Qt's Model/View paradigm
Thanks for the reply. I think you helped me answer those pretty well.
To clarify back with you:
Quote:
I think I might not understand your question however I will try to guess what you mean. Storage is controlled solely by the model or an external component outside the model-view framework (the model serves practically only as an interface to data). Application is driven by the event loop, the cooperation between the model and the view is driven by signals and slots.
- Quite right - the model will perform the necessary storage
Quote:
I don't understand the question. The view is usually a single component.
- That answers my question perfectly
Foremost I do not want to confuse the business logic of the application and as you say the view shares some of the responsibility of the controller in this case that is something I would like to keep separated out. That leaves the delegate and the event loop to share the Controller's responsibility. Im focusing on right now how I can divide the input logic, business logic and UI logic throughout the application structure.
What I am doing is writing a desktop application for win32 (no intention of deploying on mobile) for content editing and manipulation and can end up been quite a sizable application. So no service layer since its not a client server app either.
I don't need to do anything funky with the application just get my head around how I am going to piece the application together using a framework that two developers can work on.
It is possible to implement another MVC framework with Qt, that is not a problem though what I do like about Qt's MV that I have been playing with are the Models. This I like alot.
J
Re: A professional opinion on Qt's Model/View paradigm
Quote:
Originally Posted by
jerome
Foremost I do not want to confuse the business logic of the application and as you say the view shares some of the responsibility of the controller in this case that is something I would like to keep separated out. That leaves the delegate and the event loop to share the Controller's responsibility. Im focusing on right now how I can divide the input logic, business logic and UI logic throughout the application structure.
I don't think that's even possible. You'd have to rewrite all views to forward all event handling to an external component. And since QAbstractItemView is designed to cooperate with the model in a specific way (using signals and slots) your extra component won't have much freedom in what it can do.
