What are the main drawbacks of using Presentation Model in code behind?

Question

I am trying to prepare myself for being challenged with the question:

"Why cant we just implement the presentation model in the code behind?"

In fact I have worked on a project where we used a Presentation Model that was implemented in the code behind. It worked fairly well, we were even able to run unit tests on it. Yes you have a dependency on WPF in your unit tests... but it does work!

What then, are the main drawbacks of using code behind?

I do prefer the idea of an independent ViewModel (MVVM) but at the moment I do not feel able to justify it to clients.

Answer 1

You answered the first part of your question, having to to bootstrap a wpf application during unit testing. The other is portability, do you want to be able to attach diffrent view implementations to the same presentation model. (Weak I know but its all you got)

Also the seperation of skill set, only developers that know xaml would be involved in the actual creartion of the view. Allowing you to utilize exisitng in house talent that does not know wpf.

Answer 2

The straightforward answer is the principle of separation of concerns. Of course, someone might argue that by putting the presentation model in the code-behind, it is separate from the view (XAML), but I don't agree with that. The code-behind can "see" all the internal details of the View because it is the View. Both the xaml and the code-behind are compiled together into one class to become the View. They are not separate at all.

There are lots of examples where you have to go into the code-behind to do view-related stuff, like hooking up interactions between controls that you just can't specify in Xaml. Once you do that, you now have your view logic intermixed with your presentation logic.

The concept of a ViewModel is quite powerful. ViewModels can "talk" to each other without the Views "talking" to each other, or even without the ViewModels "knowing" anything about the views.

Answer 3

Check this two videos to get some idea. Both videos show developing application starting with everything in code behind and then they refactor to MVVM pattern.

• Mike Taulty's series of videos (in fact there is 10 videos in total, check at least first and second)
• Jason Dolinger on Model-View-ViewModel

Also, see this SO question for more links: MVVM: Tutorial from start to finish?

Answer 4

it is become a drawback when you use ViewModel-First approach. where in your main application you instantiate your ViewModel object graph, assign it to the root view datacontext and then lets the view render its related child based on ViewModel notification.

Why it is a drawback? the fact you can use your code behind but you'll ends up with a bounch of tricks and sometime should forgot your application security. But actually this approach is the ideal one, where your viewmodel totally ignorant, even you can reverse your development process by program first - skin latter. (joking)

in the other hand if you use View-First approach, then there will be no drawback, because viewmodel sit on it. because control still in the View if you need something tricky like using password box then just do that naturally like what Microsoft fated us..

Hope it help.