We are building an app using the MVVM pattern, we have controllers that wire up all the views and viewmodels using DI. All examples of MVVM I've seen are really simplistic and have 1 view. How do/should viewmodels talk back to the controller? The controller knows about the models and views, should the viewmodel send events back to the controller? Where should a save happen? Model? Controller?
+1
A:
Could your ViewModel not take a dependency on an IController or some other interface, so they can talk back to it? I try to keep as much application logic out of the ViewModel as possible, as these classes can easily become bloated.
MyViewModel(IController controller)
{
this.controller = controller;
}
void Save()
{
this.controller.Save();
}
I do agree that the MVVM frameworks tend to be too simplistic with their samples. In particular, moving between views/screens in your application is something I would like to see more examples of. I create an IViewManager interface, to allow my ViewModels to request that we move to another view.
Mark Heath
2009-09-25 13:29:56
Well the controller knows about the viewmodel, we don't want a 2 way dependency happening or the chance that a viewmodel my be reused by another controller.
nportelli
2009-09-25 21:09:44
Hmmmm, I'm not entirely sure I understand what pattern you are using. Are you saying you have one controller per view? Isn't that more MVC than MVVM? Maybe you could add a little bit of example code to your question to show how you create a view and a viewmodel.
Mark Heath
2009-09-26 05:52:53
One controller per view no, one controller per use case. Sorry if I didn't make that clear.
nportelli
2009-09-28 14:07:44
+1
A:
I use a similar setup to you. In my controller, where my DI and view injection goes down, I sometimes keep reference to the ViewModel (which hold the View). Some cases I may have an event on the VM which is handled by the controller. In other, extreme cases (like if the VM/V was created outside the controller, say in another VM), I may even use the EventAggregator (with a strong ref) to listen to events that may be fired on the VM. In that case, a stored ref to the VM is not needed.
Jeremiah Morrill
2009-09-25 22:09:01
Our controller doesn't know about the VM. Just and interface to the view. The VM is injected from there. The idea is that the controller doesn't know about the pattern the UI is implementing, so we can potentially swap out the UI easily. Which is leading to our problems I think.
nportelli
2009-09-28 14:12:32
+1
A:
We use Controllers too but in our case they are responsible for the application workflow. The Controller knows the ViewModel and the Model but not the concrete View because this will be injected by the IoC Container.
If you are interested in an example that shows more than just one UI (modal dialog, wizard with conditional workflow) then you might have a look at:
WPF Application Framework (WAF) - http://waf.codeplex.com
jbe
2009-10-02 16:53:13
Ya we are doing things the opposite. Our controller knows about a view interface and injects the viewmodel and model.
nportelli
2009-10-27 14:26:15
A:
How about using events wherein the controller subscribes to VM events or using a mediator pattern where in a mediator is injected in a VM.
P.K
2010-06-25 18:53:27