Is it alright to use Code Behind of View to be View Model in MVVM?

Question

In all tutorials about MVVM, I see code behind file is of no great use as we are trying to shift all the logic in view model. Is there any specific reason why we dont use Code Behind file itself as View Model?

I understand benefits of MVVM over typical code behind codes with events and book keeping, but I am trying to explore possibilities of using code behind with MVVM.

Benefit is, I can have my Model as a some dependency property, second binding and communication between two views becomes easier as just Model is bound everywhere. All that is left are commands, be it in Code behind of view or in seperate View Model what will be the difference?

Answer 1

One goal of the MVVM pattern is to separate the logic from the user interface. Using the code behind file as the view model you put the logic and the user interface together. If this doesn'n bother you, you even don't have to use MVVM.

Answer 2

A central idea behind MVVM is testability. It's straightforward to write unit tests that exercise the properties and methods of a view model. Most view models are simple enough that you'd have to be a pretty dedicated TDD geek to do this, but there are plenty of applications where there's enough logic embedded in the UI that you want to be able to regression-test it.

If you embed that logic in code-behind, the only way you can test it is by manipulating the UI. Writing automated tests for UIs is a hard problem - hard enough that almost nobody does it. MVVM certainly doesn't eliminate the need for UI testing, but it splits off a huge chunk of what manual testers would ordinarily do and puts it in a place where it's easy for machines to test.

Answer 3

Event Handlers

An unexpected happiness I've found when switching over to M-V-VM is that I have many fewer Event Handlers -- I have more triggers and databinding and actions instead. Since hooking events and failing to unhook them is a huge cause of memory 'leaks' (e.g. reference cycles, trees of invisible objects hooked together via event handlers, etc.), I've just eliminated a class of bugs from my shipping process.

Code behind is re-pleat with Event Handlers. The IDE autogenerates them for you. You'll all but pushed into using them. M-V-VM breaks this (imho bad) habit.

Answer 4

Swapping GUI Frameworks

Not sure whether you should use WPF from the Desktop CLR to build your GUI? Or Silverlight? Or ASP.Net? Or AJAX/HTML5?

If you use M-V-VM, you can swap out your GUI library used to create your View much easier. Chances are if you have to rewrite your View in a new technology, the ViewModel (e.g. application workflow) and Model will stay relatively the same. You may need to modify the ViewModel to take into account a different navigation or databinding technique, but much of the underlying structure will stay the same.