VCSM - An SOA/RIA Friendly MVC Upgrade

Anyone who's done any web-development in the last 5 to 10 years is probably familiar with (or has at least heard of) the MVC (Model-View-Controller) design-pattern. The pattern is adopted by more-or-less every notable web framework in every development language, from PHP to Java to ASP and to Flex.

In its simplest form MVC is merely a separation of layers, i.e. the Model is responsible for data access (be it from a DB, a CSV file or a Web Service), the Controller is responsible for encapsulating business logic surrounding processing of user actions, and the view simply represents information passed back from the controller to users in different forms. An MVC solution has the advantage that you can theoretically change any of the layers independently of the others.

This pattern has worked well for traditional web applications, but some frameworks and developers are beginning to struggle with how to fit in SOA hook points or RIA toolkits into the mix. I've rencetly started using the Zend Framework for a PHP project and going through various online tutorials on Dojo/YUI/Web-Service integration reveals a lot of different approaches to the problem. Whilst this isn't really surprising, especially in PHP-land, I thought perhaps a more generalized architecture would help develop better new-age frameworks.

What I have in mind is a View-Controller-Service-Model architecture (I never liked how MVC names the Model before the View even through these two never talk directly to each other). In this design, the new Service layer is the business-logic wrapper around the raw Model, encapsulating all functionality into discrete functions. Controllers are then demoted to simply calling the relevant Service operations and perhaps performing some customized error-handling or data transformation in preparation to pass to the Views.

Why the extra layer? Today's web applications are no longer discrete technology packages - a PHP web-application may need to use any number of different RIA toolkits from different technology familier (JavaScript/Flex/Silverlight/JavaFX). RIA toolkits typically have their own concept of a controller as most of the code executes within the user's browser (a YUI DataTable widget for example is responsible for retrieving data from a backend, adding editors and event-handlers, performing validation logic and displaying all this to the end-user). Trying to mesh this together with a vanilla MVC framework can lead to many cludges.

Having a clear separation between a Controller and a Service means the Controller is independent of the operation being performed or the application invoking the operation. This frees you to create server-side PHP pages using the vanilla Zend Framework MVC implementation or rich client-side pages using your favourite toolkit that bypass the server-side controllers. The end result is greater flexibility in hot-swapping interfaces, which also means your application is integration friendly (depending on how you design the Service layer, I'll give an example of a simple, multi-format PHP implementation in a later post).


  1. You're right, but your limited concept of what MVC is and isn't ha caused some confusion.

    Most people these days agree that sticking lots of business logic in the controllers is a Bad Thing. Models should fat, "modeling" your business domain. Controllers should be as thin as possible. The big reason for this is reuse. There's a decent discussion of this here:

    Also, there is no reason that Views can't talk directly to Models. That is exactly what Zend_View_Helpers do. In traditional desktop-MVC, views talk to models all the time.

    So, the "Service" layer that you've invented here is really no invention at all. You really just realized that all this business logic should live in the Model. But your limited concept of what can go in the model (you seem to think it should just be a glorified db abstraction layer) made you think you couldn't stuff it in the model, so you came up with this "service layer" concept.

    I structure my Models in ZF based on pattern that I think came from Matthew Weier O'Phinney. Yeah, he's pretty smart.

    If you've not read these two posts, I highly recommend you do:

    Though I tend to eschew Zend_Form for most projects, as I want more flexibility than you can (easily) get with it. Instead, I code my form markup by hand, and have a bunch of validation stuff in base classes that my model classes derive from.

  2. Hi Tim,

    Thanks for your comments and you're spot-on. I realized when I got to the end of my rant that I was just moving the business logic from controllers to the model, as most have always done it seems. I was under the misconception that models should be used for data-access only, i.e. VOs, ORMs or DAOs, when really that's a lower abstraction that should sit below the model.

    Matthew's domain-model and domain-gateway class is basically the same as my service class so I guess we're on similar wavelengths (although his posts are much more informed than mine, a good read).


Post a Comment

Popular posts from this blog

Wkhtmltopdf font and sizing issues

Import Google Contacts to Nokia PC Suite

Can't delete last blank page from Word