2

I am building a POS/Inventory/Book keeping app for a local SOHO, and I was wondering if I should base all my domain objects to QObject.

I came from vba/MS Access programming, am very sick of writing SQLs everywhere, duplicating data access codes, and stuff, I would like for once write a good abstraction of my data - and I figured Qt Signal and Slots might provide that for me.

All model would then simply be a list/tree of QObjects, CRUD forms would modify the object -> object then signals any model it is part of, model signals any view connected to it, bam all is well and abstracted away.

Qt property system is also useful to roll a simple ORM, as I design my own tables and therefore hate ORMs that do it for you ^^

But then I read this question, and begin wondering have I overengineer this?

Mind you, I know that I would never get away not writing SQLs inside the app anymore, not until LINQ come to C++ anytime soon ^^... But the point is I'm trying to do at least one thing right this time.

Community
  • 1
  • 1
Evan
  • 492
  • 1
  • 3
  • 15
  • as the answers to the question you have linked to say if your class is not going to make use of anything 'provided' by QObject then there's no need to inherit it, that sounds about right. Qt provides abstractions such as [QSqlQueryModel](http://qt-project.org/doc/qt-4.8/database.html), to me it sounds like a lot of unnecessary work to build your own from scratch and end up with basically the same thing. afaik ORMs don't design tables just maps the persistence layer as objects, which from what I can tell is not quite the same as what Qt's SQL abstraction does. – T I Jul 20 '12 at 19:37
  • QSqlQueryModel is a joke. So is QSqlTableModel. You can't do anything more useful than displaying data with it. This is actually the intersection I'm at: use domain objects or data models. Both provide its own level of abstraction, and I wanted to try domain object's abstraction for a good change – Evan Jul 20 '12 at 19:53

1 Answers1

2

QObjects have some weird properties that you might not want in your data classes:

  1. They have an ownership tree built in. Each QObject maintains a parent pointer and a list of its children (which it deletes when it gets deleted).
  2. They are considered "entities" - this means they can't be copied. No copy constructors and no assignment operators. For this reason (and to avoid bloat from #1), the QT datatypes (QString, QHash, etc.) aren't QObjects.

If you decide you don't want/need these, here's what I'd recommend instead: Keep your classes "vanilla," but store them in a QObject descendant from QAbstractItemModel. This keeps your data classes as small as possible, but lets you display them in any descendant of QAbstractItemView with minimal work. Your model then gets whatever signals and slots are desired to manipulate the underlying data classes.

In fact, even if you do make your data classes QObjects, having a model "manage" the collection is a pretty good idea. It's only a little bit of extra code, and it makes displaying things refreshingly easy.

Hope that's useful!

Xavier Holt
  • 14,471
  • 4
  • 43
  • 56
  • 1. yes this bloat I am well aware of, and would investigate the trade off. 2. Well, real world entities are like that - you can't have duplicates/clones. equal operator? you mean assignment operator right? not equality operator? pointers along the way huh... really makes me think twice.. – Evan Jul 20 '12 at 20:03
  • @Evan - Yeah, assignment. I was drawing a blank at the time. – Xavier Holt Jul 20 '12 at 20:55