Again MVVM / MVP story , passing interface of a view to its view model why it is bad?

Question

I have used WPF for an Enterprise solution (hundreds views heavily used Data inputs and validation) in MVP pattern (it was a clean solution usually small amount of code behind forms and main code was in pretension layer which we called it user interface process or UIP layer )

For the next small projects I used WPF with MVVM. generally some ideas of MVVM looks nice like commands and bindings especially the concept of ViewModel (having a special version of Model dedicated for View)

But I did not like so much the concept of Messaging and event aggregator I usually try to minimize usage of this patterns (for example between ViewModels I use ordinary Object oriented function call or from a View to ViewModel (I have ViewModel in my View so I use them to call ViewModel from View) but for a call from a view model to view I use messaging. though sometimes in place of sending messages (from ViewModel to View) I send an Interface of view to its ViewModel and use that interface to call a function in a view. Any body can tell me is this practice an anti pattern and why it is bad?

Answer 1

Seems fine to me. ViewModel defines an interface it requires View to implement. But you should only use this when you can't use data binding properly. Eg. you want view to do some action that is not tied to data the view presents.

Why I think this is fine is: The major point of MVVM (or MVP for that matter) is to remove direct dependency between View and ViewModel in either direction. In MVVM, this is mostly achieved by heavy use of reflection in data binding. But sometimes that is not enough, because you cannot easily invoke some action on View from ViewModel. To do that, you create abstraction that represents this action so ViewModel can call this abstracion and View realizes this abstraction. This way, there is still no direct dependence between View and ViewModel, but you can overcome the limitation of data binding.