QT Model/view Framework parsing (data is obtained from the real "meat (raw)" model provides meat, so a series of reading and writing files, operation database, network communication and other work in the model do)

    Recently in the Model/view Framework of the QT, search on the Internet, as if the Chinese in addition to a few translations there is no valuable article. E In addition to the official introduction of QT, other articles are very few. See a foreigner in the blog wrote Model/view is he think the most bad part of QT. Is that really the case? In order to give back to the open source community, I wrote this blog, writing is I think more valuable stuff. The topic is parsed, but there is no special detail about the introduction, donuts, interested TX can continue to discuss. The information I have read is "C + + GUI programming with QT 4, Second Edition", QT official website and QT source code.
    In the UI, the most common is list/grid/tree (in Qt, the grid is called table). In particular, for those database-related programs, it is possible to use a list or grid for each interface. In Qt, they are categorized as item view class. There are two implementations, one called item based, and these class names end with widgets, such as Qlistwidget. The other is called model based, and these classes end with a view, such as Qlistview.
    The item based widget is very simple to use, similar to the Clistctrl/ctreectrl in MFC. These classes are both data container and display (presentation), as well as handling interactions with users (user action). But the disadvantage of using these classes is that they do not seem to work when dealing with large amounts of data. I remember using CListCtrl's report mode to show that more than 50,000 records would have to wait a long time. Because it's going to copy all the data and show it, for example, the list can only show 50 records at a time, but it also copies the remaining 49,950 entries into the memory, and adds the formatting and other information to each record's display. I think this implementation is unacceptable for professional software. So how to improve their performance? Some people come up with virtual List/grid. They do not need to load all the data before they appear, if there are 50,000 records, it shows the first 50 at the beginning and shows which one to pick. That is, after 49,950, it does not matter, when the user moves the scroll bar or the upper and lower keys to change the display, it calculates according to a series of parameters which currently need to be displayed. such as 1000-1050, then go to take these data display. Due to the implementation of a certain degree of difficulty, so a lot of MFC implementation of Virtual List/grid show is "Vegetarian Yan" (can quickly show it has been good). Of course, coding endless, this way of fetching data we call delayed fetch, if the implementation is not good, when the speed of the computer and the user quickly drag the scroll bar may also appear white screen, trailing, blurred and so on. So you can also do prefetch and caching to try to avoid these situations. Well, there are enough mats here, we are heading straight to the subject.
    Model based view is what we want to focus on today "resolution". The corresponding UI class has qlistview/qtreeview/qtableview. So what is the difference between these view and the above widgets? The name is the biggest difference. Widgets are meant to be small things, and view is very "atmospheric" views oh. So how do these view brothers show? Here's what I don't want to say, but I have to say. A design pattern: MVC (Model/view/controller), model for data set, view representation display (presentation), Controller Handling and user interaction (User action). The MVC pattern originates from Smalltalk and now seems to be used a lot. It actually frees up classes like CListCtrl described above because they have to do a lot of things and are too tired. Also, for some programmers, implementing a class that is functionally complex can be difficult. Divided into 3 classes each class solves different problems that might be better implemented. From a software engineering standpoint, the decoupling of this approach can reduce system risk. Well, about MVC, you want to know more, you can continue to search the Internet.
    Pattern is MVC, so how does Qt come true? I opened the website introduction of QT (http://qt.nokia.com/doc/4.6/model-view-programming.html). I was dizzy, I saw dozens of classes, and many of them had inherited relationships. It's easy to lose people. But it doesn't matter, after 2 days of study, I made a summary of them, see. TX can start from my picture, grasp the main line of the framework, lest lost in the boundless Tears (class) Sea:-)

    In general, the model does not really store data (the data can be stored directly in the model), its data is obtained from the real "meat (raw)", such as a disk file, or database query result set and so on. So what is this model for? To put it bluntly, it is responsible for acquiring and providing the "meat" data to the view, and then updating the view's changes to the "meat" data to the real "meat". So, a series of working with data, such as read-write files, operational databases, and network communications, is done in model. Sometimes "meat" may be really fat, so the model has an important job is to put these "meat" number. This is the very important class of model index. In general, it uses a 2-D number (Row/colum) to number "meat". But for the hierarchical data of tree, a parent index is added as the 3rd number. That is, a father under the leaves are numbered from 0, 0, to obtain the model index when the return implementation. OK, now model has a bunch of "meat" of the number of numbers, who will buy ah? "Meat" is cheap ...
The view appears in a timely manner, noting that many view can buy the same piece of meat at the same time. (Khan, no kidding, this blog fast water). When the view needs to display some data, they get the data from model by model index (call model's data function, and when the model data changes, it will automatically send datachanged signal to all the view so that they can be updated). Of course, you can also call the model's SetData function in view to set the data corresponding to a model index. Here to illustrate the model data, with qvarient to carry, can be all types of Qt support, more intimate is that the data can be divided into multiple roles (role), such as QT::D isplayrole dedicated to display, QT:: Backgroundrole is used to display the background color and so on. So in model, you can not only number "meat", but also "meat" for "deep processing" to make them more "good-looking" or more "delicious."     The view organizes the data and displays it, but does not actually display the work, and the real work is left to the delegate.
Delegate is the C in MVC. View lets it display when it is displayed in the Paint function. Of course, you can overload this function and implement your own display. You can also set the row delegate and Colum delegate for a view to be dedicated to row and Colum. When the user triggers the view's edit trigger (such as double-clicking the mouse or carriage return), the view begins with place edit (beginediting). Delegate will create a suitable widget (such as line edit or combo box) in the appropriate place to process the user's input, delegate get the user's input and return after the user input is completed. These inputs can be saved to the real "meat" by calling the model's SetData function. So     Delegate is actually responsible for the final display of data and the processing of user interaction.
    Since the user interaction, the most important is definitely the user's choice. Say something about the selection model. View stores the item index selected by the user in the selection model, which is displayed according to the contents of the selection model. In addition, multiple view can share the same selection model, so that when you select one of them, the corresponding item in the other view is also selected.

    Finally, I'm not sure how Smalltalk implemented MVC, but the QT Model/view Framework's implementation of MVC is based entirely on C + + 's virtual base class and virtual function features. In addition to the application of Signal/slot, the interconnection between the parts of MVC is all virtual functions. TX If you are interested, take a look at the classes that begin with qabstract in the Model/view Framework source code, which define a unified interface virtual function, only the derived classes need to re-implement the functions. Here are the 2 main lines that TX should focus on when learning this part.
    Regardless of the view, the function is to show the data, then the first main line is how the data from the data source display to the view.
    The displayed data may be modified, so the second line is how the modified data is updated to the data source. If you can draw these 2 sequence maps, I believe you've got it all figured out.

    I don't know if Qt's design here is doing too much decoupling. Flexibility is enough anyway (model/view/delegate can inherit), but it can't get the programmer to grasp it quickly. Although Qt has weakened delegate and provided default delegate for view. However, in the case of specific projects, the programmer will most of the time to rewrite the number of derived classes according to the specific circumstances. This can be difficult for programmers who want to quickly interface and display. In short, this wheel is done fine, but generally before use you have to screw some screws, oil.

http://blog.csdn.net/superjoel/article/details/5112120

QT Model/view Framework parsing (data is obtained from the real "meat (raw)" model provides meat, so a series of reading and writing files, operation database, network communication and other work in the model do)