,
7 tweets,
1 min read
Read on Twitter
I think, after all these years, I'm getting a sense of how I want to write desktop UI's.
In the past, as I began to grasp MV(C), I've made domain objects observable. That is, my "M" has been the domain objects themselves. I now think this is borked.
Desktop UI code, all of it, is inherently multi-threaded. You've got a thread (or a few) that are putting pixels and catching user gestures, and you've got a thread (or a few) that are doing work.
When my "M" is directly represented in the domain objects, -- in JavaFx this means using Observable based objects like ObservableList<T> and Property<T> -- I wind up with a lot of unnaturalness.
I think my next try won't do this. Instead, I'll make task-specific Model objects that are different from (and wrappers for) the underlying Domain objects. I'll fit the Model much more closely to the needs of the task, and not generalize the Domain.
I've solved all (most?) of the problems I confronted working with the M=D assumption in my current app. But I had to think really really hard, and as new things come up I'm still having to think really hard. I don't like that.
If I weren't permanently multi-threaded, it wouldn't have been so hard. But I think the threading doesn't *create* the problem, it just reveals the problem I've had all along. When I change my M=D model objects, I have to instantly change my V and C's. I can't stepwise as well.
