viewModel.HostChat = new DelegateCommand(ExecuteHostChat, CanHostChat);
viewModel.PropertyChanged += new System.ComponentModel.PropertyChangedEventHandler(ViewModelPropertyChanged);
}

void ViewModelPropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
if (e.PropertyName == “Name” || e.PropertyName == “Port” || e.PropertyName == “Address”)
{
(viewModel.HostChat as DelegateCommand).RaiseCanExecuteChanged();
}
}

public bool CanHostChat()
{
if (String.IsNullOrEmpty(viewModel.Address) ||
String.IsNullOrEmpty(viewModel.Port) ||
String.IsNullOrEmpty(viewModel.Name))
{
return false;
}
else
return true;

}

A problem I’m facing right now is dealing with the CanExecute of an ICommand to enable or disable buttons in my view. I can’t figure out how to accomplish this in the Controller.

How does all that work? What’s the ideal way you prefer?

The VM ICommand properties are again only a named placeholder for a View to bind to. Any given controller could reuse the same VM in different ways, by assigning different ICommand code/delegates.

If your ViewModel has ICommand properties set for various commands such as ProductAddedCommand, are you simply defining the methods in your Controller and assigning them after instantiating the ViewModel?

viewModel.ProductAddedCommand = new DelegateCommand(AddProduct, CanAddProduct);

Or are you taking a different approach?

Basically whatever code you would have in your viewmodel at the moment, to populate data members, migrates directly to a controller. If you have an EF model in your VM, then your controller will have an EF instance (or create one when needed) and move the query results to a VM property. If you use service calls to populate data, then those service calls will now happen in the controller.

It is possible to bind DataSources to a VM as well, so you can also make a lot of drag-drop data stuff you author in XAML more flexible and not bound to a single source. All binding and datasource related operations use reflection to connect/move data so only the shape of the data (i.e. the property names) are actually important. That’s why I say “a VM provides a certain shape of data”.

The main thing to remember with MVCVM is that the individual building blocks should appear completely independant and only responsible for things they should know about. This makes them easily unit testable. The only cross-dependant parts in an MVCVM app are the controllers. Controllers do need to know about their Views, their View Models and their Data Sources/Models. Controllers are the glue that connects your otherwise independant components into an overall app. They are the app logic. Everything else is just there to serve them

I will be updating this series with examples, specifically a large multi-module Prism app, over time.

The main question I have right now… is how do the controllers go about populating all the properties of the ViewModels? I can’t figure out if it’s something that should be dependency injected, or if the controller simply goes through and sets all the properties(making sure to get every last one) to initialize it and later in methods as events are triggered.

I’m kind of at a hang up right here as I try to figure out how the viewmodel gets everything it needs from the controller, since you say the viewmodel is just a dumb container of data for the view.

Examples will definitely be helpful.