I have two Views and two ViewModels in my WPF app. I am using MVVM ViewModelLocator to transfer data to and fro between my ViewModels. Is this the recommended practice? Is there a better way to achieve this? I am currently using this code to access properties of ViewModel2 in ViewModel1
var _viewmodel2 = (Application.Current.Resources["Locator"] as ViewModelLocator).ViewModel2;
Thanks
What you are after is something like the Event Aggregator pattern. It will use a central 'aggregator' object and subscribing/raising events (with payloads) to ferry data back and forth. Yes, a bit complicated. If your scenario is complex enough for this , here is some more information from a previous SO post here
However......If your scenario is less complicated, you are ok maintaining a reference in viewmodel A to viewmodel B and vice versa. Which seems like it is what you are doing with the ViewModelLocator (which actually uses DI behind the scenes to resolve the instance of ViewModel you are after). This does not violate the MVVM pattern. You just want to be sure to clean up after yourself if during the course of your data share you are subscribing to any events across the viewmodels (same case with event aggregator solution).
If you register your viewmodels in a service locator or IoC container, you can simply fetch the reference from there.
SimpleIoc.Default.GetInstance<MyViewModel>()
Above example uses MvvmLight
Related
In my WPF application, I have several models and viewmodels. Consider an example:
The SurfaceCondition property of my RoadViewmodel changes. I want this to (asynchronously) trigger a change of the Wheel property of my CarViewmodel.
I can think of several solutions, but I sense this particular problem has a well-recognized solution. Using messages? Putting a reference in the RoadViewmodel to the CarViewmodel and trigger an update through the property? Merging the viewmodels? WPF gurus out there, please enlighten me!
Definitely not the two last solutions you propose as they violate Seperation Of Concerns (RoadViewModel knowing about CarViewModel) / DRY principles (RoadViewModel having to update CarViewModel or merging two classes).
Messages on the other hand seems like a fine, decoupled solution here. There are a couple of implementations available, for example Prism has en EventAggregator class, MVVM Toolkit has MessageBus etc. Or search for terms like 'MVVM event bus'. Now whatever you choose, know that it is always good to not use those classes directly but instead pass an interface. For example with Prism, you'd program your viewmodels to use the IEventAggregator interface only. In the actual application you pass them an instance of the actual EventAggregator, whereas during unit tests you pass the a mock.
I am new to MVVM and now doing some MVVM refactorying work on a silverlight project, suppose it is a book shopping application.
The View is a book list, I bind the title of the books to the ViewModel. So I have a public string Title { get; set; } in ViewModel, also a public string Title { get; set; } in Model (am I right?)
Now I want put a event handler to update the book title, should I put the event handler in ViewModel or Model? and what is the Model used for?
In my opinion "Neither"... Add controller classes to the mix of MVVM instead.
The problem with putting controller code in view models is that is makes them harder to test independantly. In many ways I see this as just as bad as code behind.
It seems to me that everyone assumes MVVM has no controllers as they left out the C. MVVM is really a variation of MVC "that just adds ViewModels".
Maybe it should have been called MVCVM instead?
ViewModels are only there to offload the "GUI" code from the view and to contain any data for binding. ViewModels should not do any processing. A good test is that your ViewModel is testable via automated unit tests and has no dependencies on data sources etc. They should have no idea where the data is actually coming from (or who is displaying it).
Although it can be overlooked/avoided, a Controller should be responsible for deciding what data model to display and in which views. The ViewModel is a bridge between Models (the M in MVVM) and Views. This allows simpler "separated" XAML authoring.
The pattern we are using successfully on all recent projects is to register controllers only, in modules, and initialise them at startup. The controllers are very light/slim and the only thing that needs to hang around for the life of the app listening for, or sending, messages. In their initialise methods they then register anything they need to own (views and viewmodels etc). This lightweight logic-only-in-memory pattern makes for slimmer apps too (e.g. better for WP7).
The basic rules we follow are:
Controllers make decisions based on events
Controllers fetch data and place it in appropriate View Model properties
Controllers set ICommand properties of View Models to intercept
events
Controllers make views appear (if not implied elsewhere)
View Models are "dumb". They hold data for binding and nothing else
Views know they display a certain shape of data, but have no idea
where it comes from
The last two points are the ones you should never break or separation of concerns goes out the window.
In simplest terms, the Model is the 'real' underlying data model - containing all the info for the booklist that might be needed by the application, able to get and set data from your database.
The ViewModel is an object that exists primarily to provide data binding for your View. It might be a subset of the Model, or it might combine properties from multiple Models into a single object. It should contain the necessary and sufficient properties to allow the View to do its job.
If the event handler relates to the View, then it belongs in the ViewModel. You might try using the Command Pattern (see Custom WPF command pattern example) if it fits your purpose.
I'm using MVVM Light toolkit (which I love). I currently have messaging in place for some interaction originating from the ViewModel and intended for consumption by the View. Typically these types of messages indicate the View should do something like hide itself, show a confirmation message that data was saved, etc.
This works. In the constructor for the View, I register with the Messenger:
Messenger.Default.Register<NotificationMessage<PaperNotification>>(this, n => HandlePaperNotification(n));
When I'm using the Messenger to communicate cross-cutting concerns between ViewModels (like identity), I can see that when the ViewModel is cleaned up in the ViewModelLocator, the base class for ViewModels (ViewModelBase) unregisters any subscribed messages. I don't have to do anything, as MVVM Light Toolkit handles that for me. However, when I use them in the Views, I have to expressly unregister them at Closing time, like so:
Messenger.Default.Unregister(this);
I suppose I could implement a base class for Views to inherit from.
However, it strikes me that perhaps this is a code smell to be using the Messenger in the View... it works, but it might not be the best way. I'm wondering if I should instead create a property on the ViewModel and bind whatever part of the View's elements to it. In the example of hiding a form, a property could be a boolean called "Show". As I think about it, I can see that in many cases this will result in having to write a ValueConverter. One way seems less testable. The other way seems to require much more code and perhaps the introduction of excess ValueConverters, which could become a code smell in themselves.
So (after all that build up) my question is this:
Is it preferable to use messages within the View or is it better to add properties (and potentially ValueConverters) to allow the ViewModel to drive it in a more bindable fashion?
In MVVM. ViewModel comunicates with View through DataBinding and Commands. If you need some other functionality, you need to implement it using this means.
Messaging is supposed to be only for ViewModels. Views are supposed to be "stupid" visualisers of your data in ViewModel.
The Messaging logic in MVVM Light is there for communication between ViewModels. I've never run into any communication between View and ViewModel that I couldn't solve with binding and/or commands. Sometimes I need Value Converters and sometimes I need code in the code-behind, but I've never had to make the ViewModel directly push data to the View.
This is an interesting discussion and I found this thread when I was wondering about view model to view communication. Interestingly, MVVMLight's creator seems to find it perfectly acceptable to send messages from a view model to a view. Another example of differing opinions about what is a good MVVM design.
I have a DomainView that allows you to select an Entity in my domain. The Entity is displayed in an EntityView within the DomainView.
My question is what should the 'DomainViewModel' property be that the EntityView binds to?
The Entity, with the View itself wrapping it up in a EntityViewModel and it binds to that?
The Entity, using a Converter on the binding to convert between the Entity and EntityViewModel?
An EntityViewModel, created by the DomainViewModel?
All would work, I just wondered what would be the 'MVVM-way'? My preference would be for one of the last two.
Lee
With the typical 'MVVM-way', ViewModels shouldn't be aware of other ViewModels and the relationship between View and ViewModel is 1-1.
Sounds like your real question is "How do I communicate data between ViewModels"? A common Master/Details interaction.
Are you using any frameworks? I am personally more familiar with PRISM, but the concepts are similar in MVVM Light and others. In PRISM, a good solution is the EventAggregator. The DomainViewModel publishes an "EntitySelected" aggregate event that is subscribed to by the EntityViewModel.
Another option is to inject a common service (or model, depending on your style) into both ViewModels. That service would provide a public property like CurrentEntity that is set by the DomainViewModel as needed.
Either would provide a mechanism of communicating data between the ViewModels without those ViewModels having any dependency on each other.
In MVP pattern, a Presenter has an interface of View so the presenter can call iview.DoSomething().. What about in MVVM pattern?
According to John Gossman's UML diagram http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx , ViewModel doesn't have an interface of View. So, seems like the ViewModel and View should be communicated via Binding only. (or use attached property or blend behavior or etc).
What do you guys think?
I agree with John Gossman. The way the ViewModel "talks" to the View is through Bindings only. In fact - the ViewModel shouldn't care about the View at all. It should simply make data available through properties, and it's up to the View to decide what it will dynamically bind to in the ViewModels. If the ViewModel wants to tell the View something this should occur implicit through Bindings.
A similar question was asked an hour ago - here.
The whole purpose of MVVM is to vastly reduce the amount of code in your code-behind class of your WPF form or user control. The idea is that anything that would be handled by the view in classic MVC/MVP can be translated over to the VM by using a combination of data binding and/or commands. In my general usage of MVVM I have managed to completely remove all of the code-behind in my forms/user controls and the VM has no direct knowledge of the view it is controlling. If you have a situation that really cant be handled by data binding or a command then please elaborate on your initial question and I (or one of the many, many more talented MVVM'ers on here) will try to point you in the right direction.
It typically does - through events on INotifyProperty changed, if nothing else.
Can a ViewModel talk to View in MVVM pattern?
Yes, but in a decoupled way. It’s allowed to introduce an interface IView for the communication.
The MVVM pattern is about to move the logic from the View into the ViewModel. This way we are able to unit test this logic.