Honestly -- given the amount of time I've spent adapting my own data model classes and structures to the straightjacket of various GUI or web toolkits -- not having the toolkit enforce its normative lifestyle assumptions on data structure feels like a feature to me.
I'd rather manage the state and relationships myself.
>given the amount of time I've spent adapting my own data model classes and structures to the straightjacket of various GUI
This is why every tells you to use MVC or some variant that separates out the UI from the data. IMGUI lets you bend the UI to the data instead but the real lesson is to decouple the view and the model.
I'm very familiar with MVC -- I've been in the industry for 20+ years -- but so far disgusted with the way pretty much every GUI framework expects you to handle this. In reality I may already have a data model, but often have to wrap _another_ model around my model, just to satisfy the GUI framework's constraints on what it thinks a model needs to inherit from, etc. Recently ran into this with Qt. Very frustrating.
The trick is to just accept that the UI model, the business logic model and the denormalized db model all have different goals and often times should be decoupled and adapted.
Which is why it seems almost every project with a complicated UI turns into a bloated pile of semi-duplicated boiler plate 'model' classes with little business logic. Clearly, MVC as the industry understands it, has a problem.
Which is why the original Smalltalk people -- who invented MVC -- mostly switched to Self's Morphic framework in their later projects (Squeak, etc.)
I'd rather manage the state and relationships myself.