I am using the MVVM Light framework as well as Unity for DI. I have some nested Views, each bound to a corresponding ViewModel. The ViewModels are bound to each View's root control DataContext via the ViewModelLocator idea that Laurent Bugnion has put into MVVM Light. This allows for finding ViewModels via a static resource and for controlling the lifetime of ViewModels via a Dependency Injection framework, in this case Unity. It also allows for Expression Blend to see everything in regard to ViewModels and how to bind them.
As I stated the Views have a healthy dose of nesting, but the ViewModels don't really know anything about each other. A parent view binds to its corresponding ViewModel via the static resource ViewModelLocator (which uses Unity to control the construction and lifetime of the ViewModel object). That parent view contains a user control in it that is another sub-view, which then goes and gets its corresponding V开发者_如何学CiewModel via the ViewModelLocator as well. The ViewModels don't have references to each other or know any hierarchy in regard to each other.
So here's an example of how the ViewModels do interact via messaging. I've got a parent View that has a ComboBox databound to an ObservableCollection in its ViewModel. The ComboBox's SelectedItem is also bound (two-way) to a property on the ViewModel. When the selection of the ComboBox changes, this is to trigger updates in other Views and sub-Views. Currently I am accomplishing this via the Messaging system that is found in MVVM Light.
So I'm wondering what the best practice would be to get information from one ViewModel to another? In this case, what I need to pass down to sub-ViewModels is basically a user Guid representing the currently logged in user. The top-most parent View (well, ViewModel) will know this information, but I'm not sure how to get it down into the sub-ViewModels.
Some possible approaches I can think of:
Should the sub-ViewModel ask the static resource ViewModelLocator for a reference to the same object the parent View is using and access the property that way? It seems like ViewModels going through each other's properties is not very clean and couples them together unnecessarily.
I'm already using messaging to notify the sub-Views that the user selected a new item in the ComboBox and to update accordingly. But the object type that is being selected in the ComboBox is not really directly related to this data value that the sub-Views need.
I have seen basically two approaches to this. For general cross-VM communication the event aggregator pattern works great.
For hierarchies of VMs however using a Visitor pattern may be better. With a visitor you can have information that flows through the hierarchy for example giving each child a reference to the parent VM automatically.
You can also do this with EA, but the challenge is around passing enough information in the payload of the message such that the children know it's something they should care about.
As far as VM locator, absolutely not! The VM locator stuff is stricly for binding in the UI it should not surface itself outside of that context (optimally).
My $.02 Glenn
I decided to have the sub-ViewModels publish a message requesting the needed information and then have the parent VM subscribe to that message type and key token. I don't want to overuse this communication means, but I think it will be effective for a few pieces of data that I'm having trouble finding ways to push down through the View hierarchy. Up to this point, most of the data passing has all been in response to events, but not every piece of data can be passed around in this way, especially if the data is acquired or the event happens on a different screen before the new view is even constructed and read to receive the data.
I did have a twitter conversation with some well known names in this space (Glenn Block, John Papa, and Rob Eisenberg). They suggested a number of things like a Visitor Pattern, but I wasn't sure that would work so well without a hierarchy of VMs. This could be because my design has pretty much been View-first, as opposed to a ViewModel-first approach. Another suggestion which may have been workable would be to modify my ViewModelLocator and Dependency Injection use to include the ability to pass in the data values to the sub-VMs at creation time. I had a little trouble envisioning it because of the static nature of the VML, and decided the message request solution I came up with would be more straight forward and simple for the time being. I will likely have to rethink the solution if there ends up being too many more pieces of data falling into this situation.
精彩评论