MVC As Anti-Pattern

By Brian Lesser
October 11, 2008 | Comments: 7

Recently I asked a group of developers to review how they build Web applications. With over 100 ColdFusion applications/sites in place, I wanted to see what we could do to reduce the cost of adding new applications and new features while containing our maintenance costs. Mostly I wanted to look at building and exploiting common services rather than writing and maintaining numerous standalone applications that implement similar features. For example we have several applications that allow people to book appointments and schedule meetings. Each of these applications implements some amount of scheduling and calendaring within its own database. A robust scheduling engine should let us retire a lot of our code while building more capable applications.

Part of the group's response was to review ColdFusion frameworks like FuseBox, ColdSpring, Model-Glue, and ColdBox. They wanted to see if adopting one framework would provide benefits like easier maintenance. If every application were written using the same framework it should be easier to support all of them.

With the exception of ColdSpring, which is primarily a dependency injection/inversion of control framework, the frameworks all support the Model-View-Controller (MVC) pattern. Controllers have a very important place in these frameworks. In simple terms they handle Get and Post requests which are mostly form submissions. For example a front controller can handle form submissions from multiple pages and dispatch appropriate commands so that the right models are updated and the appropriate views are returned to the user. Front controllers are an important way to bring order to what otherwise might look like a mess of unrelated web pages and business objects.

But what if you are building a web application with a rich client? For example, if you are using Flex or AJAX and don't need to submit any forms? Do you still need an MVC framework?

I think the answer is most likely no. I don't think you have to have controllers on the client or on the server.

A Brain-Friendly Guide

Head First Design PatternsHead First Design Patterns — Using the latest research in neurobiology, cognitive science, and learning theory, this book will load patterns into your brain in a way that sticks. In a way that lets you put them to work immediately. In a way that makes you better at solving software design problems, and better at speaking the language of patterns with others on your team.




MVC was developed in the late 1970s and was used in Smalltalk 80. It's been a long time since I saw Smalltalk 80 at Xerox and I don't remember MVC from back then. But, from what I've read since, for every model/view of data that could be manipulated by the user, a controller was required. The controller handled mouse and keyboard events and could pass messages on to other controllers if necessary. As GUI/application frameworks evolved, including later versions of Smalltalk, developers were not required to instantiate controllers to handle user events. Adobe's Flex framework has no controllers in the Smalltalk 80 sense. You don't have to do the extra work of instantiating a controller to find out when a menu item is selected, a list is scrolled, or a button has been pressed. You just ask those components to tell you when an event occurs via their addEventListener method. If you use data binding you often don't even need to use addEventListener or write code to handle events and then update controls. The Flex framework can often just take care of simple updates for you.

I think it may be helpful to make a distinction here between how post Smalltalk 80 application frameworks work internally and how developers can cost effectively use things like the Flex framework to build applications. Developers who use modern rich-client frameworks do not have to create controllers to manage events. What a runtime and its frameworks do internally is a different story. In the case of the Flash/Flex event system and Flex data binding, they are designed to make adding controllers unnecessary. So much so, that Flex add-on frameworks structured around controllers look like anti-pattern bolt ons to me. The component hierarchy in Flex provides an easy way to implement some facets of hierarchical state management. Events that can't be handled within a container can bubble up to a container that can handle them. Front controllers break down the modularity of applications by forcing you to wire up events at a global level and make hierarchical state management less practical.

Rich Client Web Application Layers

Earlier I mentioned that I wanted to look at building and exploiting common services rather than implementing similar features in each application. Simple standalone Web applications only need three layers: presentation, domain, and data source. The presentation layer is responsible for displaying information and responding to user requests. The domain layer is where all the "business logic" and domain model reside. It is the heart of the application. The data source is most often a relational database. Of course the boundaries between these three layers are somewhat porous. Stored procedures contain business logic. Client-side validation code enforces simple business rules and may implement simple workflows. But, in general, it is not too difficult to divide traditional thin-client Web applications into presentation, domain, and data source layers - even if those layers are distributed across different physical tiers.

Now, let's consider what happens to application layers when we start building applications based on services like a scheduling engine or content management system. A well-known approach to this problem is to split the domain layer into two parts often called the application and domain layers. The result is four layers:

Presentation - display information including application state and handle user input.
Application - implement workflow and transient application state.
Domain - this is the domain model that represents entities in the business model and implements business rules.
Data Source - database or other infrastructure.

Splitting application state and workflow off from the domain model makes it easier to build applications on top of services. There is no need to have a 1:1 mapping of one application to one domain model. For example, applications may make use of a scheduling service, course management system, user management service, and a CMS. Others may only use the scheduling and user management services.

Returning to rich-client applications and the physical boundary between client and server what does this mean? I think it means that an application's server-side business logic will be mostly transactional and that most everything else, including a lot more business logic, will happen on the client.

If the role of application servers is reduced to transactional business logic there is little need for handling user actions on the server like form submissions and the idea of implementing front controllers as a matter of course for every application or service starts to look - at least to me - like an anti-pattern.

Of course not every application is a rich-client application. Some applications need to present a forms-based Web front end for one class of users and provide a rich client application for others. Something like a front controller probably makes sense for the forms-based part of the application. But, I think it needs to be isolated for just that purpose, and that it's time to expunge the idea that controllers are always essential to handle user actions. I think it's time that Web application frameworks start to catch up to where desktop applications frameworks have been for a long time. If the strategy pattern is needed it can be used. That doesn't mean we always need controllers.

References

Design Patterns, Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson, and Vlissides.

There is a section in the first chapter of the book titled Design Patterns in Smalltalk MVC, where the initial Smalltalk MVC pattern is related to the patterns the authors chose to describe later in their book. For example the Model-View in MVC is similar to the Observer pattern, the Smalltalk CompositeView class supports composite views which are similar to the more general Composite pattern, and selecting a Controller subclass to implement a response to a user action is similar to the book's description of the Strategy pattern. Of course those are only three of the book's 23 patterns.

Here are two papers on Smalltalk MVC that provide some idea of what Smalltalk MVC was about from a developer's perspective:

Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC), Steve Burbeck

A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System, Glenn E. Krasner and Stephen T. Pope


I highly recommend this article from Martin Fowler for a thoughtful and historical perspective on the evolution of rich client systems:

GUI Architectures, Martin Fowler

Paul Williams, with Adobe consulting, takes a closer look at Martin Fowler's presentation patterns by implementing them in Flex.

A short blog post from Sho Kuwamoto created an interesting discussion on Flex and MVC:

MVC Considered Harmful

And, James Ward posted a Flex Best Practices video here with some interesting comments on MVC frameworks and related things.

Much of what I've written here on application layers is a pale reflection of what you can find in these two books:

Patterns of Enterprise Application Architecture, Martin Fowler et al.

Fowler's first chapter describes layers in Web applications, in particular the "Three Principle Layers" while the second chapter introduces service layers and organizing domain logic.

Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans

Evan's fourth chapter has a nice discussion of layered architectures including the User Interface, Application, Domain, and Infrastructure layers. His focus on isolating the model in the domain layer and description of the "Smart UI" anti-pattern are worth careful reading in light of how easy it is to build rich-clients using frameworks like Flex.


You might also be interested in:

7 Comments

But what if you are building a web application with a rich client? For example, if you are using Flex or AJAX and don't need to submit any forms? Do you still need an MVC framework?

I think the answer is most likely no. I don't think you have to have controllers on the client or on the server.

Emm, the reverse is true!

It is specially in a Rich Application (Ajax etc) that MVC applies best.

Smalltalk apps didn't have any forms after all, they had a rich UI, non unlike Flex or AJAX.

And, after all, even if you are not submitting forms as in html form elements, you still submit data to a handler all the time -and this is the essential part, not whether the transmission mechanism is a form, an AJAX call or a Flex handler binding.

Now, depending on the scale of your app you could consider the merits of Model1 vs Model2 implementation.

There is a pleasant discussion of this article on the ActionScript 3 Design Patterns blog at:

http://www.as3dp.com/2008/10/12/is-mvc-obsolete-flex-actionscript-30-and-the-mvc-design-pattern/

Thanks to Bill Sanders for starting the discussion:

http://www.as3dp.com/about-us/

Of course you do! MVC does not have anything to do with submitting forms. That's a mere implementation detail. Even on a RIA you still need the model, or better said, still use the model. Even though you can use another paradigm, the fact that you do not send a form to a server does not preclude the pattern.

Hi, this is exactly why I struggled so hard with your flash communication server book. You make huge claims, with little discussion and by citing lots of references. This could've been a useful article but instead it just makes you appear to be trying to be clever.

You clearly don't know what you're talking about. MVC, as the term is applied to server-based application frameworks, is only very abstractly similar to the original MVC notion or the use of MVC in every context other than the web.

Me thinks someone learned about design patterns from J2EE books and *not* from their original designers.

Hi Troy,
After George's comment I reread what I posted here and and realise there is a lot more I should have added to this article. But do you feel the glancing description I gave of MVC2 is so wrong? For example, I wrote:

"Controllers have a very important place in these frameworks. In simple terms they handle Get and Post requests which are mostly form submissions. For example a front controller can handle form submissions from multiple pages and dispatch appropriate commands so that the right models are updated and the appropriate views are returned to the user."

I realise it is brief, but is that such a bad summary of the C in MVC2 (aka what controllers do in server-based application frameworks)?

Flex applications, like complex Ajax applications, move a great deal of presentation and event management off the server and onto the client. With the client doing a lot more, the server should be able to do a lot less.

A Flex client can send a well-structured set of data directly to a remote method on the server. Surely that's quite different from what a browser sends to a URL in a non-AJAX app? Since the Flex client is sending well-structured data (likely representing a transaction) the remote method on the server only has to validate it and then use the data to complete the transaction. It doesn't have to do low level work like transforming a query string into an action or command. It doesn't have to route the command. And it doesn't have to update a complex model in server memory for the purpose of creating an HTML view that the server sends back to the client. This makes me question the need for full MVC2 frameworks on the server when developing in Flex.

I also think that developing in Flex more often resembles developing desktop applications in things like VB than developing HTML form-driven applications for Web Application servers. So I thought a discussion of the history of GUI frameworks starting back with Smalltalk made sense. I think the fact that Smalltalk style MVC frameworks were abandoned in frameworks designed for desktop applications is significant. (I enjoyed reading what Martin Fowler has written about this.) It's also my opinion that it doesn't make sense to try to take MVC2 frameworks and fit them into Flex. MVC2 frameworks were invented to solve a different problem. In that respect I'm glad to see things like Mate explore different options (message bus) for event management instead of trying to fit MVC2 style event handling/controllers into Flex.

Yours truly,
-Brian

News Topics

Recommended for You

Got a Question?