Generating the ViewModel

Question

Lets say I have a scenario in which I'm wanting to display a business object that is built up of many other business objects, i.e it is deeply hierarchical.

To display the data I would want to use a masterDetail type of view but with many many levels letting me dig deeper and deeper into the data.

So I'll want to select an item from some list at the root of the object, and show its detail view of properties, then select an item from that detail view and show its detail view etc etc.

If I wasn't interacting with the data, then I wouldn't need to create viewModels for each Model within the deep hierarchy, as I could just bind straight to the Model.

If I was interacting with the data, then I might want to wrap the entire business object and its descendants with view models, and bind to that, allowing me to add commands to perform certain logic.

But what if I only want to interact with data at certain levels? trying to interact with the model directly from XAML or codeBehind would be messy. Yet wrapping the whole thing with ViewModels is a lot of work.

Im thinking that I would just use converters to create viewModels at specific points

<DisplayControl DataContext="{Binding A}">
   <DisplayControl DataContext="{Binding B}">
      <InteractionControl DataContext="{Binding C, Converter{ConvertModelToViewModel}}">
      </InteractionControl >
   </DisplayControl >
</DisplayControl >

but what if I then need to perform cleanup on those Viewmodels? such as unregistering from events. Every time I go back and forth to the same item it will create new viewmodels for the same Model. I dont want to rely on garbage collection as keeping the viewmodels around could be expensive depending on what they're doing, and GC might not even occur (such as if Im registering to events of static classes). Using weak events would help with GC, but it still wont help in the case of keeping around expensive viewModels longer than they need to.

Answer 1

It is not easy to give a general answer to this question as it refers to the architecture of an MVVM application and there are many aspects to consider. It probably helps to sort the decisions to make and provide a couple of best practices. An answer to this will always be opinionated as it involves matters of style and taste...

A real life, complex MVVM application cannot be built without a fair bit of infrastructure which is often ignored by the tutorials. Especially for the construction of views, ViewModels and models as well as for glueing everything together there are many concepts available.

I will just give you an idea of how I have dealt with the problems you mention:

I never bind to models directly. ViewModels tend to become more complex as the application grows and the ViewModels which don't contain any additional logical aspects (compared to the model) are really, really few. Change notification (INotifyPropertyChanged) is another aspect: It makes sense to isolate this aspect to the ViewModel, as long as the change notification is required for UI purposes only. I recommend spending the extra effort for the sake of maintainability and scalability. You don't want to be forced into a major redsign just because you forgot something at the beginning.

Implement infrastructure to deal with common MVVM tasks, like synchronizing a collection on a ViewModel with a collection on a view. See the answer here for details. I ended up building a ViewModelFactory which deals with construction and caching of ViewModels. This even allows recycling of ViewModels (take a ViewModel instance that is not needed any more and just switch the model, similar concept to UI virtualization in recycling mode).

Of course, this is not a full answer to your question but I hope it helps you to go further. If you've got more specific questions, feel free to get back to me.