I hate MVVM!

It seems like sacrilege to say that I hate MVVM. So before you start crafting your emails in response, let me say, it’s not true. I like MVVM.

Before MVVM, I had created a few Silverlight applications and I wanted to tell other developers about what I thought the best practices were for developing line of business applications in Silverlight. At first, all I had was a group of patterns that I didn’t like. I found myself putting too much code in the code-behind of user controls; I’d prefer none if possible. I also found that there was a real problem orchestrating asynchronous WCF calls with the presentation and handling all the possible user interactions at the same time. I needed to point developers to a pattern quickly or else there would be a ton of messy Silverlight code developed, God forbid.

I learned about MVVM and some of its implementations and pointed developers in that direction. When they were done I looked at the results and I didn’t like their implementations of MVVM. There three are basic concepts that are at the root of my disapproval.

The first is “Separation of Presentation and Business Logic”. We have taken this too far. We have taken the idea of separation of concerns and let it creep into the presentation layer itself. We have tried to stop the tight linkage of visual representation and application logic just to say we have loose coupling. Did I want loose coupling here? Is application logic and business logic the same or really two different things? Does my application presentation need tight coupling with application logic and loose coupling with business logic?

The second issue is the case of the fat, obese, ridiculously huge view model. Not only are we putting data manipulation and validation in here, but we are jamming all sorts of commands in here too. And even worse, since the view model is, in most cases, one or more flatten business models, it has an identity crisis. Having fat a view model with an identity crisis can’t be good for your application. View models also have a life expectancy issue. How long do they live? Where do they live and how do I find them? On top of all that, why do I find view models with WCF code in them? The view model has become the black hole of code, sucking in any code that doesn’t have a home to gravitate to.

Finally, the third issue I have with Silverlight MVVM implementation is that I feel that XAML is treated like a criminal. XAML is something to be locked up, contained and monitored in Blend with graphic artists as its wardens. I find this very disappointing. XAML is so powerful and extensible it could serve as the foundation of not only the UI specification, but the application specification too. It was made for greater things in my opinion

So what does an architect do when he see a problem repeating itself over and over? He creates a framework of course. I spent the last year of spare time creating a framework called MPC. Why MPC? Mostly because at first I really thought I didn’t like MVVM and wanted to name it differently and MVC was already taken (a couple of times). But as I created the framework and worked with it, I realized it wasn’t anti-MVVM but more like MVVM+.

The main features of MPC

1. XAML is used as an application specification

2. Tight orchestration between visual state, application state and available user actions

3. Light weight view models

4. New first class citizens presenter, controller, model, state, and state action

5. Abstraction layer of service context for SOAP WCF.

MPC is an implementation of many different patterns using XAML as its core specification tool. So let’s talk about the pieces and parts of MPC.

Presenter

The idea of the presenter is not new, it’s been with us for a very long time now and it does primarily the same things in MPC as it does in other frameworks, it presents the user interface. It’s a place holder, a container, for visual aspects of the application. In MPC, the presenter is an uber content control that can have one or more states. It also acts as a host and scope for models, aka view models.

Controller

Like the presenter, the idea of a controller has been around for a long time. In MPC is does much of the same things as it would do in other frameworks like orchestration of the presenter, its states and actions. It also provides hooks and handles for unit testing the application’s logic.

Model

A model holds data, specifies how the data is validated and notifies interested parties when the data changes or becomes invalid.

State

A state combines a visual template with available actions.

State Action

State actions are asynchronous commands that manage their own threading and availability and can be reused.

Service Context

Abstraction layer for SOAP WCF service calls. They provide a simpler loose coupled interface for asynchronous remote procedure calls.

Part 2

vince

Last edited Apr 25, 2011 at 6:09 PM by solb10, version 8

Comments

No comments yet.