Is this breaking the MVVM pattern?

Question

We've been having discussions lately as to what is acceptable to put in the code behind of a view, and what should go in the view model. I seem to be a lone voice, and wanted to hear what others have to say, as I haven't yet heard an argument that explains
why I'm wrong, other than "That's not the way we do it," or "Because it breaks the pattern," neither of which are very compelling technical reasons. I'm keen to do it right, but only for the right reasons.
As an example, suppose you want to create a quote for a customer. On the new quote details window, you click a button to open a PickCustomerWindow, from which you choose a customer, and are taken back to the quote details window with the customer selected.
(I know this isn't necessarily the optimal way to do this, but it fits closely with how a lot of our windows work, so please bear with me)
Now, others in the team insist that the "right" way to do this is have the customer list window send out a message with the picked customer, and have the quote details window's view model pick up that message and set the customer. I feel that this
obfuscates the code for no apparent benefit (see below for why).
I would prefer to do it as follows. The quote window's view would have code like the following in the event handler for the appropriate button...
private void PickCustomer_Click(object sender, RoutedEventArgs e) {
PickCustomerWindow pcw = new PickCustomerWindow();
pcw.Closing += (_, __) => {
if (pcw.Customer != null) {
((QuoteDetailsViewModel)DataContext).SetCustomer(pcw.Customer);
pcw.ShowDialog(this);
The SetCustomer() method on the QuoteDetailsViewModel class does the same as a ProcessMessage method would do, in that it gets a customer and does whatever the view model needs to do with it. The difference is that the SetCustomer() method can be accessed directly
by the view that opened the PickCustomerWindow.
If you wanted to simplify this code even more, you could omit the null check and have the view model do that, but I don't think you gain a great deal by that.
In the words of Laurent Bugnion (creator of the MVVM Light Toolkit)...
"Only put in the VM what should be tested by unit tests, shared with other projects, etc. If you have some view-only code, it is perfectly OK to leave it in the view only. If you need to compute some condition deciding if the child window should be
opened or not, it is OK to create a method doing the calculation and returning a value, and to have the view call this method."
I would say that my approach fits very well with his words.
Now, I know that people like to keep code out of the view, and with good reason. However, the code above is so simple that there is no reason not to put it in the view, and you end up with a super-simple process that is easy to follow. If you want to know what
happens when you click the button, you look at the view's code-behind, and can see the whole story. You can put your cursor on the SetCustomer() method and click "Navigate to" and you are taken directly to the code that deals with the customer.
Writing unit tests against this becomes extremely easy. You simply create a customer entity, pass it to the SetCustomer() method and test whatever property of the view model is supposed to reflect the change. Very easy.
Now, compare this approach with sending a message. Having looked at the quote window's view code to see what window gets opened, you need to go to that window, find out what its view model is called, look in the view model and find out what message is sent
out when the customer is picked, find all usages of that message type in the solution, examine each one in turn to find out if it's the one that's relevant to you, and only then can you see what happens to the customer. That's a lot of messing around and a
lot of wasted time to follow a simple process. In the code I showed above, you don't even need to look at the PickCustomerWindow or its view model, as you don't need to know what they do. All you need to know is that the window has a Customer property that
returns the selected customer (or null if one wasn't selected).
Furthermore, in order to write unit tests against the view model, you either have to simulate sending a message, which is a messy experience, or you have to make the ProcessMessage method public, which exposes something that has no reason to be exposed.
A similar question comes up with using the event-to-command pattern, which I also feel is abused in the name of "doing it right." What is the point in the view sending a command to the view model, so that the view model can raise an event to tell
the view to do something? The view already knows what it's supposed to do, so why not just let it do it? Yes, if there is testable code that is involved this needs to go in the view model, but then you just add a public method and allow the view to call that.
Please re-read the end of Laurent Bugnion's words above, and you'll see that this is exactly what he suggests. What is the point of complicating the code with events that have no benefit at all?
I'm all in favour of doing it the "right" way, but only when it really is right. A method that obfuscates the code for no reason isn't what I would call right. By contrast, a method than uses clean, simple and easily testable code, that can be understood
immediately is defintely what I would call right.
Does anyone have any comment one way or the other?
FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers (Silverlight client only).
Download from the Visual Studio Gallery.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at
http://dotnetwhatnot.pixata.co.uk/

Answer 1

Hello, thanks for the reply. I appreciate your time, and any comments below should be taken in that light! Yes, I'm going to argue back, but merely because I want to understand the logic here.
>Handling click events of button in the code-behind of a view breaks the pattern
Call me a heretic if you like, but I'm not interested in hearing this. Patterns are not carved in stone, never to be questioned. Patterns are established ways of doing something
that have a specific benefit. (emphasis mine!). If I'm going to obfuscate the code, I want to know what the benefit is. Being able to hold my head up in dev meetings saying I don't break the pattern is not a benefit to me. Writing better code
is, and that's what I'm trying to find out. I want to write better code, even if it breaks the pattern.
>All application logic, for example what happens when you click a button, should be handled by the view model
What is your definition of logic? Maybe it's just my mathematical background, but to me, logic is code that makes decisions, ie testable code. A single line of code that opens a window is not logic, and does not need testing. Why does it need to be handled
by the view model?
More to the point, why does a view model even have to know about windows? A view model should be completely view-agnostic, meaning it could function just as well with any view. The fact that the incoming customer (in my previous example) came from a window
is irrelevant to the view model. All the view model needs to know is that it has been passed a customer. If you start allowing the view model to know about the UI, then you are mixing the layers.
>Using your solution, how are you suppose to unit test what happens when a button is clicked without the view?
You don't! That's precisely my point. The code I showed doesn't need testing,
because it doesn't contain logic. What you need to test is what the view model does with the customer that it was given. How the view model gets the customer is not something (at least in an example as simple as mine) that needs testing.
This is where I really can't see the obsession with shoving everything into the view model. If you have simple UI-related code that doesn't need testing, why not put it where it belongs, ie in the view?
>Using an event aggregator or a messenger doesn't necessarily makes the code or the control flow easier to understand but it  makes the components more loosly coupled to each other
Well, the view already knows about the view model, it has to, or it wouldn't be able to bind stuff to properties on it. I don't see that having the view call a method on its own view model is increasing any coupling. The other way around would be, as it
would prevent you from testing the view model in isolation.
Thanks for the reply, but to be honest, you've not really done much more than repeat the same sort of things I've heard before. I still haven't found any technical justification for the extra complexity. As far as I understand it, the ultimate purpose of
these patterns is to allow you to test each piece in isolation, and the way I suggested provides for that, whilst keeping the code simple. What you are suggesting doesn't seem to offer any technical benefits, such as easier or more thorough testing, but does
make the code significantly more complex.
Please let me repeat that I really do appreciate your time, and am not trying to be rude or arrogant. I really want to understand why people insist on doing the way you are suggesting, but I want to understand it from a technical benefit point of view. What
can I do better this way?
Thanks again. I would be interested to hear what you have to say to my comments.
FREE custom controls for Lightswitch! A collection of useful controls for Lightswitch developers (Silverlight client only).
Download from the Visual Studio Gallery.
If you're really bored, you could read about my experiments with .NET and some of Microsoft's newer technologies at
http://dotnetwhatnot.pixata.co.uk/