Dan Schultz, Intrigue Media

Lately I’ve been experimenting and researching with a lot of various UI architectures that either derive from model-view-controller, or depart from it completely.

After using Cairngorm for a dozen or so projects, you begin to ask yourself, “Is there something out there better than this?” I literally felt like Cairngorm turned me into a robot – create event, create event type, create command, add to front controller … create event, create event type, create command, add to front controller … wash, rinse, repeat. This mundane process finally put me on a quest for a better solution.

Some argue that Cairngorm is best suited for enterprise level applications where you have multiple people all working on the same project, and sharing the same files. From my experiences, I would disagree. You wouldn’t believe how many duplicate events and commands we had splashed around our applications. I think this is attributed to Cairngorm’s lack of defining a uniformed structure of an application. Oh yea, and lets not even start on the subject of where you have the multiple instances of a view being tied to a single model.

In my search for a better MVC solution, I had a few guidelines that the pattern should meet:

1. Separating pieces of an application into their own modules or “sections.” By doing this, it makes it easier to replace UI interaction, or add feature XYZ when your boss comes knocking on your door.
2. Reduce dependencies between each “section” of an application. I know, I’m asking a lot here; however, just because a component in a panel on the left side of your app communicates with another panel on the right side of your app, doesn’t mean they need to have direct dependencies between them.
3. Reduce dependencies between the model and the view. In traditional MVC and Cairngorm, the view is allowed to be coupled to the model, and the model indirectly tied to the view via the Observer pattern (i.e. data binding). By untying the view from the model, you now make your views more robust by being able to use it with an albeit similar, but different model.
4. Being able to work with the Flex module loading framework. Cairngorm has some issues related to this, and there are some workarounds for it, but generally speaking, Cairngorm wasn’t designed with module loading in mind.
5. Completely free of singletons. Singletons have their time and place, but a model should never be a singleton! This is like putting your data in concrete. Just because you think now that you’re never going to need multiple instances of an object, doesn’t mean that you won’t have to in the future. On top of that, singletons are nearly impossible to subclass. At the very least, have your singleton classes conform to an interface. This way you can change its implementation in the future. Ok, I’m getting off topic ..

MVC meet H-MVC – Hierarchical MVC
From my research, H-MVC is a pattern used mostly in the Java world, and is unknowingly based off of the PAC (Presentation-Abstraction-Control) pattern. H-MVC answers the following questions when architecting a UI:

• What’s a consistent way of structuring my UI code?
• What’s a good way to cleanly separate my views from my domain model, and make them reusable?
• What’s a good pattern to easily allow for application flow, and inter-component communication?

At its core H-MVC is an event based framework that makes a clean break between your models and your views. On top of this separation, it effectively allows your views and models to communicate with other parts of your application by simply firing events. This communication works by controllers propagating these events throughout the whole application. Think event bubbling in Flash, but instead of this happening through the views, it happens through the controllers.

Image taken from the JavaWorld HMVC article.

Let’s take the example where Component A is its own view that contains a single button. We have another view called Component B that contains a ViewStack. On top of that, Component B is nested somewhere in our application that is completely outside the visibility of A. When the button is clicked in A, we want B to switch the selectedIndex of its ViewStack to 2. H-MVC successfully decouples the communication by making the assumption that a parent will always know about its children, but the children never knows about its parent.

Since this post is getting pretty long, I’ll hold off showing any code examples till my next post. In the mean time, if you want to do a little reading on H-MVC, check out the original article written by Jason Cai, Ranjit Kapila and Gaurav Pal. There’s also another article that’s dramatically shorter and gives a good overview.