Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>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 <a href="http://en.wikipedia.org/wiki/Separation_of_concerns" rel="noreferrer">separation of concerns</a> 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:</p> <ul> <li>MFC</li> <li>Qt</li> <li>Swing</li> <li>SWT</li> <li>WPF with MVVM</li> </ul> <p>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 <a href="http://martinfowler.com/eaaDev/uiArchs.html" rel="noreferrer">overview</a>.</p> <p>Since there are so many different ideas what <em>an</em> 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 <a href="http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html" rel="noreferrer">original smalltalk paper</a> it says: </p> <blockquote> <p>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). </p> </blockquote> <p>In light of that I would answer your three main concerns thusly:</p> <ol> <li>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.</li> <li>I agree that you are/would be forced to merge Controller and Model (again with respect to the definition above).</li> <li>I agree, again. The Model should only manage the data of the <em>application domain</em>. This is what they call "data". Clearly, dealing with rows and columns for example has normally nothing to do with our applications domain.</li> </ol> <p>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.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload