I'd be tempted to have all the data in one model per type, as QAbstractTableModel1 with a column per data member, and then use QSortFilterProxyModels for each view to filter what data that view sees.
The first screen would be three views each showing just the name from each model, and selecting a...
I had considered a QAbstractTableModel, however the Employee, Department, and Store classes have additional responsibilities and decoupling the data from the functions doesn't align that well with OOP principles.
@19172281 Don't think of QT's model classes as models in the MVC sense. They are more like viewmodels in the MVVM sense.
@19172281 you still have your Employee, Department and Store classes, but you populate EmployeeModel, DepartmentModel and StoreModel as flat tables at the top level
@19172281 you can override QAbstractItemModel::data and QAbstractItemModel::setData to interact with your classes, but you still have to deal with adding / removing / moving rows when the underlying list changes shape, yes
Would that be an index for the parent/grandparent, or pointers? It just seems that with your approach we'd need to maintain the hierarchy in 2 places while still having multiple models.
@19172281 I'd use the id's. Each filter model will override QSortFilterProxyModel::filterAcceptsColumn to hide columns it doesn't use, and QSortFilterProxyModel::filterAcceptsRow to hide rows based on ids (that it can store)
Ah, no object references at all. Just indexes to find the data via manager? E.g. for Employee, an entry might be something like, 3,1,7. Which gives us the 7th Employee of the 1st Department of the 3rd Store.
Discussion between Caleth and 19172281
Discussion between Caleth and 19172281