I\'ve got a WPF application which calls MessageBox.Show() way back in the ViewModel (to check if the user really wants to delete). This actually works>
Just in case anyone else is still reading and unsatisfied:
I just wanted to handle 'notification' type MessageBoxes (i.e. I don't care about the DialogResult), but the problem that I have with most solutions I've read about is that they seem to indirectly force you to choose your View implementation (that is, currently I have a MessageBox.Show, but if I later decide to just fiddle with the visibility of a hidden panel directly in my View, that won't mesh very nicely with an INotification interface passed in to the ViewModel).
So I went for quick and dirty:
The ViewModel has a string NotificationMessage property, with changes notified to PropertyChanged.
The View subscribes to PropertyChanged, and if it sees the NotificationMessage property come through, does whatever it wants.
OK, so this means the View has code-behind, and the name of PropertyChanged is hard-coded, but it would be hard-coded in the XAML anyway. And it means I avoid all the stuff like converters for Visibility, and properties to say whether the notification is still visible or not.
(Admittedly this is just for a limited use-case (fire and forget), I haven't given much thought to how I might want to extend it.)