I lost you at "Talk to the View"

FirstName · Originally posted by mikedfox

   In the Happy Hour sample, I was following your reasoning for doing what you did, and was 
pretty happy with the approach you took. Having code behind call a method in the viewmodel, for example, was a great example of pragmatism over purism.

But the interface mechanism int "Talk to the View" seems not only a real violation 
of the MVVM model, but an unnecessary one, as well. I'm trying to figure out why you went 
wth the approach you did (the interface) instead of something that works similarly without breaking 
the model: putting an event in the ViewModel, and hooking it from the view.

So for the problem given, I would:
- in MainPageViewModel, add 
public event EventHandler DrinkOrderAdded;
- in AddDrinkOrderMethod of MainPageViewModel, add 

if (DrinkOrderAdded != null)
	DrinkOrderAdded(this, new EventArgs());

- in constructor of MainPage.xaml.cs, add

this.DataContextChanged += MainPage_DataContextChanged;

- in MainPage.xaml.cs, add

void MainPage_DataContextChanged(object sender, DependencyPropertyChangedEventArgs e)
{
MainPageViewModel vm = (sender as MainPage).DataContext as MainPageViewModel;
vm.DrinkOrderAdded += _viewModel_DrinkOrderAdded;
}

void _viewModel_DrinkOrderAdded(object sender, EventArgs e)
{
DrinkName.Text = string.Empty; 
DrinkName.Focus();
}

It's a little more verbose (mainly because there's no built in event 
where we can hook the viewmodel event, but seems to do the job without 
violating the model on one hand, or requiring a whole message passing 
engine on the other.

Thoughts? Am I missing something?