Reducing Code in the Code Behind Files

Topics: Prism v2 - WPF 3.5
Oct 13, 2009 at 8:59 PM
Edited Oct 13, 2009 at 9:45 PM

Whilst building my first Composite WPF application I came across the following issue and although I have a wayaround the problem I am not sure if my assumptions are correct.

I have a ListView and I wanted to data bind to fire a Command on the MouseUp event.   Realizing this is not possible by default to bind a command to such an event  I then simply created a method for my command on the PresenterModel class and Hooked up a standard windows event on the Mouse up which then calls the PresenterModel Method in the Code Behind.  

This works fine however I am not happy for the following two reasons.

1.   I feel I should be using the CompositeWPF command mechanisms and I really wanted to Databind the commands

2.   Usinf the MVVP patterms I try to keep the code behind as minimal as possible ( ideally nothign in this file if at all possible ).

Having searched this forum for a possible solution I came across the following implementation of a snippet which if I understand it correctly, will solve my problem but then I need to have one of these classes for each control and event type that I need to handle.

http://blogs.southworks.net/dschenkelman/2009/08/13/c-code-snippet-to-create-commands-with-attached-behaviors-using-prism/ 

So I go from 5 lines in the code behind file and a method in the PresenterModel to needing two classes and the associated command in the Presenter Model file.

Can someone tell me if I am missing the point here or if there is an better way of addressing this issue?

Oct 13, 2009 at 10:47 PM

Hi Steve,

If you want to reduce the code behind of your view, one of the best ways to get this done is Data Binding (whether you bind to commands or ViewModel properties). If you want to execute a specific action in the MouseUp event of the ListView, then the command with the attach behavior will definitely work.

However, as you said, it adds some classes to your application to attach the behavior. This is when your requirements get into the mix. If you want to handle the MouseUp event because you want to check the recently SelectedItem in the ListView, another approach could be binding the currently selected item to your View Model and perform the required action in the property setter.

Although the above example is kind of simple, I hope it helps understand my point.

Always have in mind that the one of the goals of reducing the code behind is having a “more testable” view, so you should also put that into the mix when deciding between the XAML command and the code behind. The following blog post talks a bit more about the MVVM pattern, code behind and other things to take into account:

Please let me know if this helps.

Damian Schenkelman
http://blogs.southworks.net/dschenkelman

Oct 13, 2009 at 11:30 PM
Edited Oct 13, 2009 at 11:31 PM

*** Please ignore this response I see it is the Propery Setter. *****

Thanks for the swift and informative reply.  The link is very interesting I have read this before, the comments section on how to handle say multiple selection opens some interesting discussions but these are outside of my current requirements at present.

Like your idea of binding SelectedItem to a property in the ViewModel but I miss then what is observing the property in the ViewModel to then trigger the calling of say an  associated command?