How is MVVM in .Net different than MVC in Cocoa?

Question

I'm reading up on MVVM and for the life of me can't tell how the 'model-view' of MVVM is radically different than the 'controller' in MVC, as used in Cocoa programming.

I've even read some explanations that were supposedly 'aha' moments for others and have still failed to catch the difference. The limited Cocoa GUI programming I've done has involved treating the controller as the central point for managing data going to AND from the view to the model with the use of key-value observing.

In all the important aspects, this seems to me what the 'model-view' does except that it might be a subtle implementation difference that pertains to the WPF <-> C# bridge in .Net. That is, MVC in Cocoa might be called MVVM if the Cocoa GUI was specified in a different language than the application code, and the controller was coded in the same language as the GUI instead of the application (ie WPF is specified in XAML rather than C#).

Or perhaps MVC in non-Cocoa environments, without all the key-value observing, etc. is far different than MVC as applied in Cocoa and that has led people to find larger differences between MVVM and MVC than I have.

Am I crazy? Please educate me.

Answer 1

I've been a huge fan of MVVM in WPF for years now, and have recently picked up MVC in Cocoa. At first they seemed identical, then similar, and now as I work more with Cocoa, nothing alike.

My feeling is that the differences are in the direction of the binding.

In MVVM, the View binds to properties on a ViewModel object (V -> VM). Change the ViewModel object's properties, and with a bit of jiggery-pokery using NotifyPropertyChanged, the View magically updates itself. The View passively reads off properties in the View Model object, and the ViewModel knows absolutely nothing at all about the View - you could delete the View and it would still work. This gives you the flexibility to rewrite, change or combine views and have them "just work" without changing a line of view model code.

In MVC under Cocoa (iOS), the view controller binds itself to the view (VC -> V) through explicit IBAction/IBOutlet properties - you have a direct reference in your view controller to the view objects. You directly tell a control on the view to change in your view controller, and the ViewController has intimate knowledge about the internals of the View. Delete the View, and the ViewController will throw runtime exceptions.

For me it's about the direction of the binding.

With Cocoa using the MVC pattern, you are directly "controlling" the view through the view controller (stand to reason, right?).

In MVVM/WPF, you are having the view control update itself by watching for changes to the ViewModel object - the binding is the other way around and passive.

WPF without MVVM is just like Cocoa MVC for iOS, and feels a bit like ASP.NET forms.

Cocoa for OSX does have a more MVVM-like binding strategy available, but that isn't available on iOS.