CODEWITHSUNDEEP
qtarchitecture
avb
avb

Reputation: 1751

Should a QAbstract*Model derived class belong to the backend

I have an application in which I want to have strict separation between backend and frontend(GUI).

The backend is the application logic with cpp classes and the frontend are QML files with some cpp classes which mainly works as adapters to the backend.

Now I was wondering if it is okay to have classes derived from QAbstract*Model in the backend form a design point of view.

My first thought was that they should NOT belong to the backend because they are just a wrapper around some Qt Container classes to reflect their data in the GUI. So a pointer to the actual data can be injected and they should only be used in the frontend for displaying purpose but they should not be used anywhere in the backend.

The Qt Container classes of course should belong to the backend.

Now I also need some conversion and utilities functions which act and maybe modifies the data of the containers. Therefore I wrote a 'handler' class. But now it is starting to get tricky to keep everything in sync especially without getting bindingloops.

The other solution would be to have a class derived from QAbstract*Model which wraps the data and also have these conversion and utilities functions. They could then call the dataChanged etc. functions. Then I could use this class also in the backend. But would that be good design or should the backend be free of QAbstract*Model derived classes?

Since I find it quite difficult to express my issue clearly, I hope my question is understandable in some way :-)

Upvotes: 0

Views: 126

Answers (2)

Vladimir Prus
Vladimir Prus

Reputation: 4650

In a 100% pure design, I'd have model classes independent from Qt model/view framework, and then create a QAbstractItemModel on top of that. That will be the Model-View-ViewModel architecture, not the classic MVC.

I think this is good design because QAbstractItemModel deals a lot with presentation - things like column numbers, or display roles. If these are kept separate from the model, you can change the presentation without touching the model at all, and the model can be smaller, or even implemented in standard C++.

In practice though, if your model adds/remove children, and you want to show that in your view, mapping between C++ and Qt becomes quite cumbersome. So, unless your have specific requirement to keep Qt out of model, or have particular interest in doing this, just have QAbstractItemModel-based class in your backend.

Upvotes: 2

Aurel Branzeanu
Aurel Branzeanu

Reputation: 622

It is a classical MVC question, so yes, the Models are belonging to the backend, even the QAbstractProxy derived objects. It will allow easy scaling, faster responses, etc.

Sure if we are talking about large enough systems. For small ones without plans for future extending there is little sens in MVC at all.

Upvotes: 0

Related Questions