This is not an introduction to the MVC pattern, but a look into its implementation in Smalltalk-80 to understand the original intent and function of the Model, View, and Controller triad. Starting with the “classic” MVC helped me understand the evolution of the presentation patterns that came after it. We will look at how a simple MVC app works in Smalltalk-80 and examine how it can be implemented in ActionScript. I am not a Smalltalk programmer and my first task was to find some good resources.
Trygve Reenskaug is credited with the first MVC formulation in Smalltalk in the late 70′s. However, the MVC metaphor was burned into Smalltalk and matured after Reenskaug left Xerox Parc. I found two useful resources on MVC in Smalltalk-80. The first is A cookbook for using the model-view controller user interface paradigm in Smalltalk-80 by Glenn Krasner and Stephen Pope. The second resource is Applications Programming in Smalltalk-80: How to use Model-View-Controller (MVC) by Steve Burbeck.
Although comprehensive, Krasner and Pope’s article is very readable from an ActionScript perspective. I could just about follow the Smalltalk code listings, identify the early OOP features and appreciate the ancestors of contemporary UI components. What stood out was how little things have changed in the last 20 to 30 years in OOP and GUI programming. I think the more appropriate observation is how advanced Smalltalk was for its time. Krasner and Pope’s essay is the primary resource for this post.
Model-View-Controller Implementation in Smalltalk-80
The MVC pattern facilitates the separation of concerns when developing interactive graphical applications. The logic and state of the application, how users interact with the application, and how application state is presented to the user are handled by separate elements of the MVC triad. Smalltalk-80 uses the MVC metaphor to provide built-in support for interactive application development. The idea was to provide a set of built-in user interface widgets such as buttons, menus and lists that can be plugged into a GUI application. To use these built-in UI widgets effectively, the application had to be built in accordance with the MVC metaphor. Let’s take a look at the conceptual diagram of a Smalltalk-80 MVC app.
Conceptual diagram of MVC in Smalltalk-80 (from Krasner & Pope)
All objects in Smalltalk communicate with each other via messages. Think of messages as a way to invoke methods in an object.
At first glance, the MVC conceptual diagram seemed a little strange. The multitude of arrows indicated more acquaintances than I’m used to seeing in an MVC diagram. Model-View and Controller-Model dependencies ran both ways. The second interesting aspect was that user input goes directly to the Controller. This is a significant change as we generally expect users to interact with UI widgets in the View. In Smalltalk-80, it looks like the raw keyboard and mouse input is fed directly to the Controller. Let’s take a quick look at how the MVC metaphor is supported in Smalltalk-80. Read more…
Truckin' thru MVC
The MVC remains one of the most valuable structures for understanding and using Design Patterns, and yet I believe it to be misunderstood and misused on just about every level imaginable. In the first chapter of their book, the Gang of Four spend a mere two pages describing MVC in order to help readers understand the concept of a “pattern.” Unfortunately, the language used may have been the culprit leading to widespread uses for which the MVC was never intended. In introducing the MVC, GoF note,
Looking at the design patterns inside MVC should help you see what we mean by the term “pattern.”
The phrase, the design patterns inside MVC is where the trolly may have jumped the tracks.
Read more…
Truckin' thru MVC
I mentioned that updating and changing programs is the
sine qua non of Design Patterns. Further, I promised that it wouldn’t take very long to get to Part IV of this series because all I was going to do was to update the original compass program. So that’s what I did, and here is Part IV of
Truckin’ Through ActionScript 3.0 MVC.
Adding an Interface for the View
Before adding another view, I wanted to add an interface so that I could use the same Model and Controller classes. The changes are minimal in the revised View classes, and I changed the Client so that it could more easily request any view the user would like. Since you have all of the details about how the MVC works in Parts I-III, I’ll get right into the interface.
In looking at the View class in Part III, you can see that the class has only two methods. By putting them into an interface, we can program to the interface instead of the implementation. That means that as long as the same interface is used, you can use the same Model and Controller without any changes at all. As usual, interfaces are fairly short, and this one is no exception.
1
2
3
4
5
6
7
8
9
10
11
| package
{
import flash.display.Sprite;
import flash.events.Event;
public interface IView
{
function createView(vessel:Sprite):Sprite;
function update(e:Event):void;
}
} |
Before continuing, click the Play button to test both compasses that have their roots in that interface. (compi?)
The Model and Controller classes are identical for both compass examples. Read on to see how easy it is to add views.
Read more…
Truckin' thru MVC
It’s been a busy month, and finishing up a simple MVC example took me longer than I expected. Chandima’s chapter (Chapter 12) lighted the way, and I also found valuable ActionScript 3.0 examples by
Bill Trikojus and Anthony Kolber . So if you experience a sense of
déjà vu, it’s from the MVC’s by Chandima, Bill and Anthony.
Taking Control
In Part II of this series on the MVC, we saw how we could separate the Model (data provider) from the View (a representation of the Model’s data—a graphic compass.) The process was simple enough, especially since all we needed from the Model was a value between 0 and 360. We made it even simpler by using constants with cardinal directions. In this final piece of the MVC puzzle, we’re adding a Controller class. The Gang of Four state that the
…Controller defines the way the user interface reacts to the user input
The UI for the controller is a Slider component set up with values ranging from 0 to 360. The View class instantiates the Sldier with Slider change events sent to the Controller class. In turn the Controller sends the Slider values to the Model, which updates its current value. The update is sent to the View class which rotates the compass needle.
Read more…
Truckin' thru MVC
I was going over Chapter 12 in our book that Chandima wrote on the MVC. It’s one of those chapters that has everything you need to get started on the MVC; so, I’ll use it as an anchor for my comments and make references to different parts of it to so as not to be redundant—in other words I won’t repeat what Chandima has so well and clearly stated. Instead, I want to focus on moving toward problem-solving using larger structures.
Straws and Stacks: MVC as a Reality sui generis
Years ago in an introductory sociology course, I became acquainted with the concept of a reality sui generis. Some of you may have come across the term elsewhere with different meanings in different contexts. Biology, law and political science have their contextual uses of the term, but the one we’re using here is the one from sociology. Emile Durkheim employed the term in his work, Suicide, to describe a social fact. For Durkheim, a social fact is a phenomenon of social behavior not reducible to its component parts. A bureaucracy is an organizational arrangement that we think of independent of those who actually make up the bureaucracy. It is a reality sui generis—a reality in and of itself. So, we can study phenomenon like families, groups, and organizations as being separate from the people who make them up. Each has characteristics that cannot be seen in the individuals.
To help us understand the concept, we were given the example of a stack and the individual straws that make up the stack. Straws and stacks have wholly different features even though one exists because of the other. By the same token, the MVC, while made up of objects, has characteristics independent of those objects. So, we might envision the MVC as a reality sui generis.
Read more…
Truckin' thru MVC
First off, let me say that Chandima is the go-to guy when it comes to the Model-View-Controller (MVC) framework, including PureMVC. So if you’re interested in MVCs, I’d suggest you start where I did—Chapter 12 in our book and any of Chandima’s posts on PureMVC. Further, if you have GoF’s original
Design Patterns you might want to look up the several references to the MVC there, especially the initial explanation of its purpose in Chapter 1. Finally, by way of introduction, last year about this time, I broached the query,
Is MVC Obsolete? based on a post by Brian Lesser. That kicked up very little dust either on our blog or Brian’s, but it helped to take a closer look at the MVC. You’ll be relieved to hear that I’m not going to trash MVCs in this series. Rather I want to explore the MVC as a compound pattern (or perhaps framework) to see some different things we might do with it.
MVC in a Nutshell: The Great Decoupler
To get started, GoF show the MVC to be three distinct components in what they call a a triad of classes. As such, they discuss its elements in terms of objects. The application object is defined by the Model, the screen presentation by the View and the way the way the user interface reacts to the user input by the Controller. Prior to MVC, the application, its appearance on the screen and the UI were grouped together in a single class. By decoupling the objects into separate units, the MVC loosens the relationship following a key good practice. (I used to cram them all together in a single class thinking that I was tightening up my code—how dumb was that?) As a first image of the MVC, then, think of it as a tool to loosen up code.
Read more…
Although it may be a small conceptual leap for someone who has experience with the single-core version of PureMVC to visualize how multicore works, it can be a little daunting for a novice. This post describes the design and development of a simple game concept to exemplify the utility of PureMVC multicore. This is a pure AS3 app that doesn’t use the Flex framework. You can download the source and build the app in Flex/Flash Builder (as an AS3 project) or Flash CS3/4.
The basic difference between single-core ( now known as the standard version ) and multicore is that multicore allows multiple MVC triads (multiple cores in PureMVC parlance) to be embedded inside a single application. The general recommendation is to use PureMVC multicore for all projects as it affords a lot more power in terms of developing modular applications and unit testing. However, developers who are new to PureMVC should first develop a simple single-core application first to get familiar with the framework. My previous PureMVC post describing a minimalist example will get you started with the basics. From here onwards, I’m assuming that you have a basic understanding of how the standard version of PureMVC works.
Read more…
Another View of the MVC Design Patterns
A while back Brian Lesser, another O’Reilly author and top notch Flash Media Server developer, mentioned that he did not especially care for the Model View Controller (MVC) design pattern. While he cited some references, I never paid much attention to it at the time, especially since Chandima kept writing these brilliant pieces on Pure MVC. Further, I had promised myself that I wouldn’t touch MVC until I had worked my way through all of the design patterns using ActionScript 3.0 and felt comfortable with Flex. So I really am no expert of MVC and have relied on Chandima for that particular compound design.
After weeks of pounding my head on the Prototype pattern, I was thinking of taking a break and sending a torpedo into the Singleton to let off some steam. However, before sticking my neck out (yet again) I thought I’d ask Brian why he didn’t particularly care for the MVC, resulting in a very thoughtful article. (See http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.html) Brian asked for Chandima’s and my reaction. Not having spent that much time on the MVC, my reaction was based on the logic of the article which to me made perfect sense. However, this is a case of “What do I know?” The annual OOPSLA conference is coming up this next week and I will be bringing up Brian’s points to big brains that attend OOPSLA–and I hope some more Flex/ActionScript/Flash developers will be there this year! So maybe after next week I’ll have some comments from seriously bright programmers in addition to our seriously bright programmer, Chandima.
So take a look at http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.html and we’d like to get any copies of your comments, thoughts, and wisdom that have you about Brian’s article to post here as well.
Several months ago, I was looking for a framework that would streamline AS3 application development. Cairngorm and PureMVC were the most mature frameworks out there and I remember being particularly impressed with PureMVC mainly due to the solid documentation that came with it. Cairngorm may be robust, but I just couldn’t get my head wrapped around it by glancing at the docs and examples. In contrast, PureMVC came with a Conceptual Diagram that explained the framework using the design patterns that I was familiar with. Cairngorm does have similar diagrams that explain its microarchitecture, but it exemplifies my initial thoughts — I just couldn’t get a quick, big picture understanding of it easily. Not only has Cliff Hall done a masterful job on the PureMVC framework, but the effort he’s put into the documentation really underscores the importance of documentation and diagrams on dissemination and adoption.
Cairngorm or PureMVC?
Recently, Ali Mills and Luke Bayes made a presentation on Flex Application Frameworks. Their choices essentially boiled down to Cairngorm and PureMVC and concluded that PureMVC came out on top. However, I highly recommend that developers watch the whole presentation as many enterprise developers in the audience made comments that challenged the easy differentiation of the two frameworks. Having the backing of a stable organization like Adobe, as is the case with Cairngorm, means a lot for enterprise development. Also, this post on Bill Lane’s blog and several comments implying that PureMVC is much harder to learn than Cairngorm got me thinking if a really simple application would help scaffold the transition to PureMVC.
I’ve implemented the minimalist example from the MVC chapter of our book (available as a free download from Adobe Devnet) using the PureMVC framework. Now this is not a full-fledged application, but a very minimal example meant to explain the inner workings of the PureMVC framework. Before diving in, a brief introduction to some of the important aspects of the framework will help. This was the hard stuff that I had to internalize before starting out. These concepts are more eloquently explained in much greater detail by Cliff Hall in the framework documentation.
Read more…
Two chapters from the ActionScript 3.0 Design Patterns book are available as a free download from devnet. Each chapter contains multiple examples. The factory method pattern chapter includes a print shop application, a sprite factory, and a shooter game that uses the factory method pattern to create different types of projectiles. The MVC chapter includes a weather map application and a car chase app.
Bill Sanders
Recent Comments