wpf mvvm confusion

Question

as per my understanding about mvvm is.

there is a model (entity class that also implement inotify...), view (xaml code) and some class as vm (kind of controller which normally inherit icommand) to let us make events/commands to be generated on specific event...

m just wondering about difference between viewmodel class and xaml's code behind class... why don't we simply consider and enhance code behind...

no considerable reason is in my mind to justify this...

or kindly write somethng with example to clear mvvm... and why mvc or mvp is hell for wpf app????

Answer 1

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 2

why don't we simply consider and enhance code behind...

Code behind is often (always?) the simplest approach...if you're a developer. But MVVM is designed to assist more than just a developer. MVVM is for the database girl and the graphics guy too.
Separating M (for the db) and V (for the artist) and VM (for you) allows each person to work independently of each other. So, for example, you don't have to wait for the graphics guy to make a UI before you can wire up the db. You can all work in parallel (in theory).

Separation of concerns means separate jobs.

Answer 3

why don't we simply consider and enhance code behind...

(In addition to what other have already mentioned:) because it make your code easier to read. In the code behind file, you have UI stuff that is impossible or to complicated to do in XAML. In the view model code file, you have everything related to filling your form with data.

As with all design patterns, blindly following it is not the best idea. For very small windows, MVVM might not make sense. For larger windows, MVVM forces you to make a separation of concerns, which will usually make both your code behind file and your MVVM class easier to read, to understand and to debug.

Answer 4

The Model does not implement INotifyPropertyChanged, the ViewModel does. The actual WPF view data-binds to the ViewModel. There is now a lot of documentation online for this.

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

MVVM is identical to Fowler's Presentation Model, in that both patterns feature an abstraction of a View, which contains a View's state and behavior.

http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx

In practice however, only a small subset of application UI can be data bound directly to the Model, especially if the Model is a pre-existing class or data schema over which the application developer has no control. The Model is very likely to have a data types that cannot be mapped directly to controls. The UI may want to perform complex operations that must be implemented in code which doesn't make sense in our strict definition of the View but are too specific to be included in the Model (or didn't come with the pre-existing model). Finally we need a place to put view state such as selection or modes. The ViewModel is responsible for these tasks. The term means "Model of a View", and can be thought of as abstraction of the view, but it also provides a specialization of the Model that the View can use for data-binding. In this latter role the ViewModel contains data-transformers that convert Model types into View types, and it contains Commands the View can use to interact with the Model.

MVVM is associated with WPF because WPF's data binding mechanism when combined with this pattern makes testable GUIs a breeze.

Answer 5

First, for MVVM purposes you don't need the VM to inherit ICommand. Instead, VM contains a set of properties of type inherited from ICommand. So that View just binds to those properties. F.i.:

<Button Command="{Binding DoSomethingCommand}" />

And code-behind isn't used because it's basically inseparable part of the View. It's the same class your View is. You can't easily test it, and your code is often tightly coupled to the XAML.

And Model is not really obliged to (but can) support INotifyPropertyChanged. Whereas ViewModel should of course implement this interface to allow binding.

I suggest you to read a few introducing articles on the subject. It's not that confusing. This can be the first one: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx