Richard Leggett on New Media

I’ve got a stack of posts scribbled over some paper that I’ve been meaning to blog about for months now regarding the MVP pattern (and ViewModels). But more on that later, because what is core to MVP is of course MVC, that most misunderstood of “patterns"…

Well this one is for new-guns and MVC vets alike, Cliff Hall presents on MVC as it is applied in PureMVC, perhaps one of the most refreshing frameworks to come to light in the Flash realm, and it is spreading to many other languages, ports include Python and even JavaScript/JQuery in the works.

I’ve started a re-write of a desktop application I worked on some years ago that was around 50,000 lines of AS2, I can’t even remember how many commands were in there but it was quite heavy and the “front controller” took a battering, so it’s a good challenge to put these concepts into practice and take advantage of the new possibilities, such as web and AIR deployment from the same code-base.

Follow up:

Before watching the video, if you are new to PureMVC I suggest you read the “best practices” document so that you get the most out of it, the most confusing aspect of PureMVC is perhaps the class naming (although the class names are logical when you know the terms). For example, most of your code will go in subclasses of Mediator, Proxy and Command. I’ll take each one in term:

• Mediators - These “steward” your views and keep them simple, i.e. take a user interaction such as a click, and do something in your application, and the reverse, take an application event and tell a view to do/display something.
• Proxies - These provide access to your model, local or remote, and can perform domain logic.
• Commands - These are executed by the controller to perform work e.g. store some data in a Proxy. (more on this later)

You can see now how these 3 types fit into the M.V.C. pattern very clearly, unfortunately the naming can at first confuse.

Without further ramble, here’s the link to the recording. The order felt a bit reversed to me, so if you get bogged down hold out, he goes on to explain the core concepts later on. Cliff speaks with enormous experience and succinctness so even if you’re already comfortable with all of this it’s good to hear from other devs that have been through the trenches.

I guess this is a good opportunity to discuss MVC, it’s almost a dirty word now with people almost sick of hearing it, and interestingly most of us get burned when we try to “apply” it in Flash, struggling for perfection. The thing to remember is that it is not an implementation pattern, you can’t create an MVC structure per-se, and when I see people firing up a new project by creating a “Model” class that they make a Singleton and chuck all the data in I cringe* - it is in fact a guiding set of rules that dictate how the component parts of an application can be separated, governed, and how they can communicate.

*Yes PureMVC has a Model singleton/multiton, and I’m still thinking heavily on this design with regards to TDD. But either way it’s not the sort of bad singleton you see when newbies write their _global Model monoliths, instead its a simple cache for your actual models, your Proxies and as such is not the damaging monster you tend to find and it doesn’t reference any classes outside of those PureMVC.

Many of the books and articles written on the subject of MVC refer to server-side development. There’s a potential sting in the tail if you try to apply this directly to client-side, and Cliff points out in the recording that on a client application the Model becomes even more important. Remembering that on a client application the model persists, not just the data, but the state of the application, the history of the users actions perhaps, it can be much more complex and potentially confusing than when you’re working directly with a database. On a client application you have to constantly maintain a “context", users interact asynchronously in different contexts, that’s where the programmer skill comes in, and that’s why MVC helps by separating these , and why PureMVC helps by providing not just a framework designed around the principals of MVC, but also many helpful principals about where to write your code and when!

The forums are particularly useful. One simple example you encounter early on is setting data from a view… so my (view-) Mediators can access my (data-) Proxies directly, why bother sending a notification from my Mediator so that the Controller executes a Command to access the Proxy to set the data? Well a Command is a good way to bundle up some logic/actions that may get called from more than one place, more than one Mediator in this case. As such you’re avoiding duplication and edging towards more testable code.

I think that’s enough, this has been done to death over the years but it’s good to bring it up now, ultimately the most important rule is to remain pragmatic.

That video link again.