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?
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.
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.
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.
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.
Although in the final product there is a generally one-to-one mapping of view to view-model, there are a couple of reasons why you might not want to code the view model in this file.
- You may wish to swap in another view model for test purposes and thus have more than one code file
- The code-behind file can still be used (except by purists) for rendering / view logic where XAML would otherwise be cumbersome or hard to maintain. In this case you would undesirably have both view and view-model code in the same file.
Another reason beyond abstraction and testability: you may want the flexibility in some cases to have multiple Views which point to the same ViewModel.
