Missing the "Model"?

Oct 27, 2010 at 10:27 AM

Thanks for the book. I think it does a nice job of describing how to implement some of the core MVVM concepts. The perspective taken in the book of walking through the demo application works well, although this means things that you might want to think about that the application doesn't do aren't really discussed at all. That being said, it's a useful leg up for me, trying to go from MFC to MVVM in one step.

Perhaps I am being dumb, but I am having dificulty deliniating the Model from the ViewModel in this example BubbleBurst app.

I guess the model is sort of spread out across all the instances of the BubbleViewModel?

Maybe I have got completely the wrong end of the stick here, but what I would expect to see is an explicit Model class, which encapsulates the board state. This would be the place you would implement, say, load/save functionality. I guess then each instance of BubbleViewModel would have a reference to the bubble data from the model.

This gets me to the point that is missing from the book - How do you tie the ViewModel to the Model, such than when one part of the app updates the Model, another part's ViewModel & View is notified.

I'm not really sure about the BubbleViewModel/View either. It doesn't seem terribly scalable to have a view and a model for each bubble on a grid. Would it make sense to have BubbleMatrixViewModel, and custom view which renders this?

As you can see, I'm still struggling with the concepts, so perhaps this is all mindless babble.

Cheers,

Mark

Coordinator
Oct 27, 2010 at 3:00 PM

Hey Mark,

BubbleBurst doesn't have Model objects.  The focus of the book is on interactions between ViewModel and View.  That was the area I saw people asking the most questions about, which is why I decided to focus on that in my book.

Regarding your question about how to detect Model updates from multiple "parts" of an application, the answer is that the Model must be observable.  You can have the Model classes expose events that are raised when state changes, or use a Messenger to broadcast messages, etc.  Each ViewModel that references a Model object would need to listen for those events/messages/etc.

The scalability concern you expressed about rendering each bubble with a separate View does not phase me at all.  Unlike typical MFC UIs, WPF element trees can be quite large without there being a noticeable performance decrease.  Element composition is the way to go, not having a custom paint routine or something to that effect.

Josh

Oct 27, 2010 at 4:20 PM

Interesting to know.

Thanks,
Mark