Prism-Unity-MVVM + Interface to handle custom control from ViewModel code/logic/events

Topics: Prism v4 - WPF 4
Jan 9, 2013 at 2:51 AM

We are building an application that has a lot of very specific requirements regarding View - User interaction. We are using MVVM + Prism & Unity, but we are seeing a lack of Command features & Binding expressions to facilitate most of our (even basic) requirements relating to taking action on the UI from code/logic in our ViewModels. We have entertained raising events from the ViewModel and interfaces to allow for abstracted communication to the View to do any number of very specific (basic) things from Focusing a certain control to Selecting text in a TextBox.

We have settled on creating an Interface over events due to the event subscription overhead/liability.

I know that many people on any given forum will claim that events and interfaces are a "no-no" while proclaiming that "zero code-behind" is the way. The number of additional ViewModel properties and extra work to add attached/dependency properties for each and every View feels less maintainable than allowing an interface to abstract any given UI implementation that needs to be invoked by code/logic/events in the ViewModel.

Are interfaces acceptable for this use case? Discuss in general.


Jan 9, 2013 at 3:17 AM
Edited Jan 9, 2013 at 3:19 AM

To follow - It appears that this has already been specifically addressed here:

The IView description is exactly the usage that we are implementing.


The types participating in this pattern are:

  • View contains the specific GUI controls and defines the appearance of the user interface.
  • IView declares the interface of the View. The ViewModel can communicate over this interface with the View. Related pattern: Separated Interface (PoEA).
  • ViewModel represents the state and behavior of the presentation.
Jan 9, 2013 at 4:26 PM


In my opinion  there is not only one way to separate the visual presentation concerns from those related to visual logic. Hence, you should use the one that suits best to improve the maintainability and testability of your application. Based on my understanding MVVM's primary concern is about producing maintainable UIs for the developer and the designer, hence if using the IView interface approach suits best for the requirements of your scenario, instead of directly using data bindings, commands, EventTriggers and behaviors which are commonly used in MVVM, then I believe it should be fine to use it.

Particularly, I haven't experienced with the approach mentioned the suggested link, but it seems to benefit of different separated UI patterns, and as far as I know the Prism Library itself is intended to be neutral with respect on which separation UI pattern you choose as you can be successful with any of these patterns. For example the use of the IView interface is common when using the Presentation Model pattern which can be seen in many of the quickstarts provided in Prism v2.


Agustin Adami