Question

I think that the terminology used in Qt with model/view controls is flawed. On their explanation page they state, that they simplified the MVC to MV by merging View and Controller and they are giving the following picture:

However I think, they misnamed the roles of objects and I think that,

1. What they call View with merged Controller is in fact a View only.
2. What they call Model is in fact Controller only.
3. If you really want to have a model it would be somewhere where their “Data” is.

I am speaking about usual and sane way you would use Qt model/view component in your app.
Here are the reasons:

1. This is typically Qt component which is used as is, without adding any Controller logic specific to your objects)
2. This is hardly a Model, just because you should implement several Qt methods like rowCount, columnCount, data etc. which have nothing to do with your model. In fact there are typical model methods found in Controllers. Of course, you can implement both Controller and Model logic here, but first it would be quite bad code design and secondly you would merge Controller and Model not Controller and View as they state.
3. As said in reason 2. if you want to separate Model logic that it is surely not the blue box on the picture, but rather the dashed “Data” box (communicating to real Data of course).

Is Qt wrong in their terminology, or it is just me who does not understand? (BTW: The reason why it is not academic question is that I have started to code my project following their naming and I have soon found out, that the code clearly is not right. It was only after that when I realized, that I should not try put Model logic in what they call Model)

Answer 1

I agree with you that Qt’s naming is misleading. In my opinion however, the problem is not Qt’s alone, but is shared by all frameworks that allow us to adhere to the principle of separation of concerns when implementing our UIs. When someone comes up with such a framework, and finds a good way to keep “things” separated, they always feel obliged to have modules that they call “Model” and others that they call “View”. Over the years I have worked with these frameworks:

• MFC
• Qt
• Swing
• SWT
• WPF with MVVM

If you compare how the terms “Model” and “View” are used in these frameworks, and what responsibilities the classes in the “View”, the “Model”, and the “Controller” (if there is one) have, you will find that there are very big differences. It would certainly be useful to have a comparison of the different concepts and terminologies, so that people switching from one framework to another have a chance to stay sane, but that would require a lot of work and research. A good read is Martin Fowler’s overview.

Since there are so many different ideas what an MVC pattern can look like, which one is correct? In my opinion, the people who invented MVC should be turned to when we want to know how it is supposed to be implemented “correctly”. In the original smalltalk paper it says:

The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

In light of that I would answer your three main concerns thusly:

1. In fact a Qt component “manages the graphical […] output”, and “interprets the mouse and keyboard inputs”, so it could indeed be called merged View and Controller with respect to the definition above.
2. I agree that you are/would be forced to merge Controller and Model (again with respect to the definition above).
3. I agree, again. The Model should only manage the data of the application domain. This is what they call “data”. Clearly, dealing with rows and columns for example has normally nothing to do with our applications domain.

Where does it leave us? In my opinion, it is best to figure out what Qt really means when the terms “Model” and “View” are used and use the terms in their manner while we are programming with Qt. If you keep being bothered it will only slow you down, and the way things are set up in Qt does allow elegant design – which weighs more that their “wrong” naming conventions.