StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<h2>Short answer</h2> <p>Qt's MVC only applies to <strong>one data structure</strong>. When talking about an MVC <strong>application</strong> you should not think about <code>QAbstractItemModel</code> or <code>QListView</code>.</p> <p>If you want an MVC architecture for your whole program, Qt hasn't such a "huge" model/view framework. But for each list / tree of data in your program you can use the Qt MVC approach which indeed has a <strong>controller</strong> within its view. The <strong>data</strong> is within or outside of the model; this depends on what type of model you are using (own model subclass: probably within the model; e.g. QSqlTableModel: outside (but maybe cached within) the model). To put your models and views together, use own classes which then implement the <strong>business logic</strong>.</p> <hr> <h2>Long answer</h2> <p><em>Qt's model/view approach and terminology:</em></p> <p>Qt provides simple <strong>views</strong> for their models. They have a <strong>controller</strong> built in: selecting, editing and moving items are something what in most cases a controller "controls". That is, interpreting user input (mouse clicks and moves) and giving the appropriate commands to the model.</p> <p>Qt's <strong>models</strong> are indeed models having underlying data. The abstract models of course don't hold data, since Qt doesn't know how you want to store them. But <em>you</em> extend a QAbstractItemModel to your needs by adding your data containers to the subclass and making the model interface accessing your data. So in fact, and I assume you don't like this, the problem is that <em>you</em> need to program the model, so how data is accessed and modified in your data structure.</p> <p>In MVC terminology, the model contains both the <strong>data</strong> and the <strong>logic</strong>. In Qt, it's up to you whether or not you include some of your business logic inside your model or put it outside, being a "view" on its own. It's not even clear what's meant by logic: Selecting, renaming and moving items around? => already implemented. Doing calculations with them? => Put it outside or inside the model subclass. Storing or loading data from/to a file? => Put it inside the model subclass.</p> <hr> <p><em>My personal opinion:</em></p> <p>It is very difficult to provide a good <em>and</em> generic MV(C) system to a programmer. Because in most cases the models are simple (e.g. only string lists) Qt also provides a ready-to-use QStringListModel. But if your data is more complex than strings, it's up to you how you want to represent the data via the Qt model/view interface. If you have, for example, a struct with 3 fields (let's say persons with name, age and gender) you could assign the 3 fields to 3 different columns or to 3 different roles. I dislike both approaches.</p> <p>I think Qt's model/view framework is only useful when you want to display <strong>simple data structures</strong>. It becomes difficult to handle if the data is of <strong>custom types</strong> or structured not in a tree or list (e.g. a graph). In most cases, lists are enough and even in some cases, a model should only hold one single entry. Especially if you want to model one single entry having different attributes (one instance of one class), Qt's model/view framework isn't the right way to separate logic from user interface.</p> <p>To sum things up, I think Qt's model/view framework is useful if and only if your data is being viewed by one of <strong>Qt's viewer widgets</strong>. It's totally useless if you're about to write your own viewer for a model holding only one entry, e.g. your application's settings, or if your data isn't of printable types.</p> <hr> <p><em>How did I use Qt model/view within a (bigger) application?</em></p> <p>I once wrote (in a team) an application which uses multiple Qt models to manage data. We decided to create a <code>DataRole</code> to hold the actual data which was of a different custom type for each different model subclass. We created an outer model class called <code>Model</code> holding all the different Qt models. We also created an outer view class called <code>View</code> holding the windows (widgets) which are connected to the models within <code>Model</code>. So this approach is an extended Qt MVC, adapted to our own needs. Both <code>Model</code> and <code>View</code> classes themselves don't have anything to do with the Qt MVC.</p> <p>Where did we put the <strong>logic</strong>? We created classes which did the actual computations on the data by reading data from source models (when they changed) and writing the results into target models. From Qt's point of view, this logic classes would be views, since they "connect" to models (not "view" for the user, but a "view" for the business logic part of the application).</p> <p>Where are the <strong>controllers</strong>? In the original MVC terminology, controllers interpret the user input (mouse and keyboard) and give commands to the model to perform the requested action. Since the Qt views already interpret user input like renaming and moving items, this wasn't needed. But what we needed was an interpretation of user interaction which goes beyond the Qt views.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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