StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Actually, the proper way to do this is when you first create a ParentVM, you iterate through the children of the passed-in Parent, creating a ChildVM for each, then add those ChildVM objects to the ParentVM's ChildVMs property. (Some would just call that property 'Children' but I personally like being clear it's a collection of ChildVMs, not a collection of Child objects. Simply adding the 'VM' suffix makes that very clear.</p> <p>You then also have to listen for change-notification to the actual Parent's Children collection and update your ChildVMs collection accordingly.</p> <p>That way you have a model with Parent->Children->Child and a ViewModel of ParentVM->ChildVMs->ChildVM which is I believe exactly what you want.</p> <p>Now I'm also of the belief that you should be able to expose the Parent directly from the ParentVM as well as the Child directly from the ChildVM since your UI might be binding to various properties on those items, such as your Name property above. However M-V-VM purists would say to never do this saying the UI should never know about the model because if the model changes, you have to change the UI. My argument is that if the model changes, you have to change the ViewModel anyway for the exact same reason. The only savings would be if there are several views all sharing the same ViewModel since you'd just have to change it in one place, but realistically, something like 'Name' isn't going to change it's "name" from the model to the ViewModel so in those cases it's a non-argument anyway.</p> <p>Plus, there is a performance overhead by doing it the 'purist' way in that you can't simply delegate to the model item like you're doing with Name above because the view won't ever know about any model-generated changes to the Name property unless you also add all the extra change notification inside the VM, meaning you now have one change notification in the model who's sole purpose is to fire a <em>second</em> change notification in the VM that then notifies the UI. Pure? Yes. Performance-invasive? You bet, especially when large amounts of changes are going on and you're using the INotifyPropertyChanged interface because that means you have to do string comparisons in the change handler to detect and delegate all those changes! If you bind directly to ParentVM.Parent.Name property however, you would already have that change notification from the model to notify the UI and you also keep your VM clean for things that are only VM- or View-specific.</p> <p>What I never do however is place anything in the Model that is view-only info. THAT to me is what the ViewModel is for. So for instance, if the children have a specific color based on an enum or whatever, that to me is something that goes in the ChildVM and not the Model itself, and if there are any properties in the model that dictate that color, like a property of that enum, in that case, yes, I would wire up change-notifications from the model inside the ChildVM. (Truthfully, I may even just do it via a color converter in the UI directly, still binding to the model's enum. It's really a case-by-case thing.)</p> <p>HTH,</p> <p>Mark</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload