What Happened to MVC?
What Happened to MVC?
Remember MVC? Model-View-Controller? It was this great idea that said
if you seperated these three aspects of an application that it would
be much easier to write and manage your code. It disappeared from
sight a few years ago. Why?
All these frameworks, Tapestry, JSP, Struts, Spring for web
applications have sprung up and none of them are MVC. Why?
Let's review MVC and see what we can figure out.
Model: This is the set of objects that define the stuff you're working
with, be it customer information for a business or strings of DNA for
Genomic research such as I work with. Much of the model will be
persistant objects of some sort. A typical public method would be
Set findMatchingCustomers(CustomerFilter f)
This would be called by a controller in a web application or by any
application that wanted to do something with customers.
View: This displays things, specifically strings and images (what else
is there to display?). It makes no decisions about the data it
displays. It doesn't know anything about the data it displays. You
should be able to completely change the code for the model and not
even recompile the view code. About the only decision the view code is
allowed to make is how to handle longer-than-expected strings and
different sized images.
Controller: These objects receive events from the GUI (mouse clicks
and user-input strings), make requests of the model, analyze the
results, and decide on which view object to call and what strings and
images to pass it.
It is essential to recognize that these three sets of objects are
completely seperate -- they live in different files, the Model and
View are compiled independently of each other. The Model code is
usable by lots of other applications.
The Model and Controller are both computational kinds of objects. They
are concerned with logical operations on data objects -- exactly what
OOPLs (such as Java) are very good at. By contrast, the View is
concerned with how things will look to the human being -- where the
strings and images will be positioned, what will be mouse-sensitive,
etc. Java is a lousy language for specifying GUI layout.
HTML is a giant step up from Java, although I still find it
If the web were the place I think it should be, this wouldn't be an
issue. Not anymore than the lousy instruction set of the x86 is a
problem for high-level language programmers. I've written gobs of C
programs and never had to worry about which register a variable was
going to be stored in.
HTML should be completely hidden from sight in the same way.
Unfortunately, the web is not that nice place and HTML hangs out of
our applications like dirty skivies on a 10-year old kid. And I know
about dirty skivies. I was a Boy Scout.
Oh, we're the boys from 33,
we aren't so very neat.
We never wash our underwear
or clean our dirty feet.
We're always filling our water buckets,
and water pistols too.
Oh we're the boys from 33.
Who in the heck are you!
So we're stuck with HTML for the time being. Fine. We can deal with
it. We have to generate the HTML anyway.
So, how should we generate the HTML? Java is lousy at it, so people
have written frameworks such as JSPs, Tapestry, Struts, Spring,
etc. These are all clearly much better than Java, but still kinda
Tapestry's not MCV?
But it says it is, right there on page 10 of Shipp's book!
Well, there's mvc and then there's MVC.
If someone points to a line of code and says "That line is part of the
Controller" and then points to the
next line and says "That's part of the View" then they're talking
In other words, they're lying through their teeth
(possibility to themselves too). They're pretending their product fits
some societly accepted norm, when it doesn't.
Here's an example of some typical code from Shipp's Tapestry book:
image='ognl:getAssets("digit" + visit.game.incorrectGuessesLeft)'
It displays an image on a page. That's View code. But what's all that
OGNL stuff? Why it's calling Model code! Oh, dear.
Can I change the name of a method in the model (say, getAssets()?)
without changing this code?
This does not mean that Tapestry isn't an effective framework for
building web applications, but it does predict a set of expected
difficulities. Adding in the fact that Tapestry is not a complied
language with declared types, we can predict:
Minor changes to the Model code will ripple through to the end users
who will discover that little used operations (which lack complete
test coverage) that used work, now either fail or display incorrect
We expect that the Controller code for deciding which page to display
next will be complex and have numerous subtle variations that relate
to the now ad-hoc nature of page selection.
We expect that when the user is in the middle of a transaction,
reissuing a previous request (because the user pushed the BACK button)
will prove awkward and often produce highly unsatisfactory results,
because it's hard to do.
If we look at radically different display paradigms, such as Swing, we
don't see these problems. Changes to the model are confined to the
model and the controller. The basic controller code for selecting the
next page to display is very simple, such as:
Set goodProspects = findMatchingCustomers(richCustomerFilter);
if (goodProspects.size() < 1000)
The final problem doesn't exist in Swing applications because there's
no independent form of navigation such as the browser's BACK button,
so that's not a fair comparision. Spring is able to deal with this
issue by adding information about the intended flow of the
application. (Unfortunately, it requires some redundant information.)
Are there better ways of writing browser-based applications than
Tapestry and Spring? I think yes, extremely yes.
I predict that someone is going to make a really big pile of money by
designing an MVC framework for web applications.
No, let me go one further. Somebody is going to design a window system
independent MVC framework that will behave indentically in browsers,
in Swing, SWT, etc.
That person is going to be rich, Rich, RICH!!!
But that's not my focus here. My only objective here is to clarify the
notion of MVC and point out some of the hurdles that have to be
crossed by the monolithic frameworks we use today. In otherwords, many
of the problems that we see with these frameworks are exactly what MVC