CODEWITHSUNDEEP
qtmodel-view-controllermodel
TheMeaningfulEngineer
TheMeaningfulEngineer

Reputation: 16359

Qt Model View pattern, design choices for connecting Model with Data

I'm trying to understand what should the relationships between the Model and the Data be.

enter image description here

For my current situation i have a QTcpServer which keeps a list of active sockets.

class TftpServer : public QTcpServer
{
    Q_OBJECT
public:
    TftpServer(QObject *parent = 0)
        :QTcpServer(parent) {}
    QList<QTcpSocket *> m_activeSockets;

The Data that the Model should represent to the View is QList<QTcpSocket *> m_activeSockets;

I feel like the right way to do it is to prevent the duplication of data at any cost for that can lead to inconsistency. Meaning that at all times View should represent the real state Data.

I have tried some approaches, didn't succeeded in any because i have limited time i can spend testing each approach.

Approaches:

1.

TftpServer::m_activeSockets private, Model accesses it through getters and setters.

2.

Model friend class of TftpServer. Directly accesses TftpServer::m_activeSockets.

3.

TftpServer::m_activeSockets public. Model has a public reference

QList<QTcpSocket *> & m_activeSockets; to TftpServer::m_activeSockets.

I would like to find out an optimal solution (feel free to suggest) is considered optimal.

And hear if their are pros of not insisting on a single Data source (in which case the model would just have a copy of TftpServer::m_activeSockets as its parameter and sync with it on changes).

Upvotes: 0

Views: 254

Answers (1)

Kuba hasn&#39;t forgotten Monica
Kuba hasn&#39;t forgotten Monica

Reputation: 98505

You're abusing Qt's model-view architecture - there's no need to pass actual sockets around. What you want is to model a list of connections, so just implement that. Connections have some parameters - those can be mapped to a model's columns, or as child rows with each connection being a parent item in a tree, depending on what's more convenient. The data a model should provide must make sense in terms of visualization. A QTcpSocket is nothing that can be visualized unless you'll be making your own custom views or delegates. Things that can be visualized are numbers, strings, etc.

What you're trying to do is to re-use QTcpSocket as only a structure with some accessor methods used to return the hostname, port and the like. You won't save any time by abusing it that way.

Upvotes: 1

Related Questions