Arden Thomas shared with us what he learned from someone “who was there”, Dianna Merry Shapiro, about the origins of MVC. (Note: The original link to the article cannot be found anymore)
One story I found interesting, was one about the MVC framework (Model View Controller). MVC is one of those basic frameworks that you usually learn along with Smalltalk, when you first cut your teeth on using ST. What I learned was that MVC was added nearer the end of the decade of Smalltalk development (after Alan Kay had left iirc), and its addition was even controversial.
I heard it a bit differently: my recollection is that Xerox had planned a demo of the project at the Xerox World Conference in November 1977. They wanted to show off a screen with several windows on it, all synchronously responding to changing the value of a counter in one of the screens. The Counter MVC demo. For this a professor from Norway, Trygve Reenskaug, was asked during a sabbatical he spent with Xerox PARC, to provide a framework that could do this elegantly, and he came up with MVC. This is recorded in Dealers of Lightning: Xerox Parc and the Dawn of the Computer Age, and maybe I should check with Stephen Pope who shared this information when he was in the Netherlands with my company, Cibit.
Now I know that mr. Reenskaug tells us that his year as a visiting scientist was one year later. So indeed the past becomes a bit blurred as to the origins of this idea.
Anyway, I share with dr. Reenskaug the dislike of what has become of it, but for me the essence of MVC never has been the building of user interface frameworks, (or, even worse, the glue for multi tiered architectures). My interpretation of the basic idea behind MVC was and still is that it is a framework to separate concerns, and mainly two:
- Business logic or domain logic
- Technology (computers, screens, keyboards)
That the user interface can be seen as technology (as it certainly was in those days) does not imply that is should be seen as such. Indeed, as our technology advances we may very well find that delegating “display” responsibilities to the domain objects themselves will lead to much more elegant and lean designs (for example, check out the Morphic system from Self, or Naked Objects).
Leave a Reply