Делаю класс, который будет отображать и редактировать таблицу из базы данных.
На форму разместил QTableWidget, отобразил на нему табличку из QSqlQuery, и добавил на форму кнопочки добавления и удаления строк, что бы редактирование было напрямую в таблицу, типа экселя.
А теперь эту схему хочу оформить в виде класса, что бы стандартизировано цеплять это множество взаимодействий к любой таблице на форме.
На вскидку можно сделать класс

class MyWrapper : public QObject {
      QTableWidget* tbl;
public:
      MyWrapper(QTableWidget* _tbl) : tbl(_tbl) {
            tbl->installEventFilter(this);
            tbl->setProperty("MyWrapper", QVariant((qlonglong)tbl));
      }
};

и в него запихать всю логику.
Или нужно это по другому организовать?

неправильно написал строку в прошлом посте:

tbl->setProperty("MyWrapper", QVariant(ptr<TMyWrapper>(this));

а управление этим объектом делается через

QCoreApplication::sendEvent(tblWidget, MyEvent)

или

tblWidget->property("MyWrapper").value<ptr<TMyWrapper> >()->DoSomething();

... но зачем?
Ведь можно использовать слоты/сигналы.
Можно использовать QSqlTableModel.
В конце концов просто создать свой виджет, который группирует кнопки и таблицу и в него вписать всю логику, которая по идее должна быть завязана на интерфейс QAbstractTableModel.
Делать свои события - YAGNI, уж поверьте.

Правльный вариант, как сказал lanz:
QTableView + Своя модель, которая реализует сохранение в БД + Виджет управления.

В первый раз такую модель делать будет тяжко, зато потом много где пригодится.