Intro to
Melbourne Design Patterns User Group
Discussion on 1-Aug-2007
On \"MVC\" (whatever it is! ;)
by O.K.
My original motivation to have a discussion on MVC was to attempt to use the collective brain of
the group to clarify the vagueness and confusion surrounding the \"MVC\" term...
------------------------------------------------------------------------------------------------------------------------------
\"the elusive wisdom\"
\"MVC\" - the three-letter acronym is used a lot... working within IT/SE/SD industry one does
constantly encounter it these days - it is mentioned everywhere, but when trying to clearly \"see it\"
and \"get it\" then in some of (if not in the most of) the contexts in which it is been mentioned these
days you'd often get a feeling that it \"escapes you\"...
Consulting the original source (i.e. \"MVC\" in SmallTalk-80) to which a reference is usually and
routinely made in those contexts where the \"MVC\" buzzword is used does NOT help, rather on
the contrary - as very often even with allowing some extrapolation and interpretation it is quite
hard to match the original thing with what you actually have in this other contexts (these \"other
context\" come in various forms and shapes - UI frameworks, web-app frameworks,
CMS, \"blueprints\", \"product/system architectures\" etc...)
This leads to frustration as you get a feeling that there is some non-esoteric but rather fairly trivial
(because everyone uses and applies it routinely and easily) piece of knowledge and/or a concept
that everyone around possesses and operates with fluently,
but which escapes YOU personally !! :(
Did anyone feel like that?
You are NOT alone!! ;)
But what is even more interesting is the fact the people who are renown OO and Design Patterns
experts and who really used SmallTalk and really used the original MVC on it have the same
problem with industry current use (i.e. abuse !) of the term...
A good view on this phenomenon can be found in Martin Fowler's 1 online updates to his
\"Patterns of Enterprise Application Architecture\" book
http://www.martinfowler.com/eaaDev/uiArchs.html
\"...Probably the widest quoted pattern in UI development is Model View Controller (MVC) -
it's also the most misquoted. I've lost count of the times I've seen something described as
MVC which turned out to be nothing like it. Frankly a lot of the reason for this is that parts
of classic MVC don't really make sense for rich clients these days. ..\"
And then, in that part of the article he strives to communicate the REAL meaning of MVC in its
original sense and explain how it is not really applicable nowadays...
1
No, I don’t work for ThoughtWorks ;)

But the rest of the industry is not as pedantic and rather than striving for technical correctness
and preciseness is embracing a use of \"MVC\" in a very broad and vague sense, more like a
“buzzword”.
The trick is that as in fact one should expect of anything that has escaped from the domain of the
experts and specialist into the a domain of journalists, marketing/salespersons and \"mass trivia\"
(\"mass culture\") it is been used rather superficially and with deliberate vagueness, the intention
often been to be \"buzzword-compliant\" rather then to infer some precise technical meaning...
A somewhat harsh, but true summary of this phenomenon is given at (good for it’s discussion and
comments) \"C2\" resource (Cunningham & Cunningham, Inc.) on \"MVC\":
http://c2.com/cgi/wiki?ModelViewController
\"...When a system obeys the principle DoTheMostComplexThingThatCouldPossiblyWork,
marketects often respond by clumping its rambling notions together into 3 groups. The
sub-SpaghettiCode group nearest the User becomes the \"view\", that nearest the database
becomes the \"model\", and the stuff in between becomes the \"controller\".
Marketects then refer to their project's architecture as \"MVC\", borrowing that acronym's
impressive lineage...\"
In fact comments like that make this \"C2\" wiki on MVC quite an interesting resource, much in
contrast with Wikipedia's
http://en.wikipedia.org/wiki/Model-view-controller
which, IMHO, serves more as an illustration of what I dubbed as superficial \"mass trivia/mass
culture\" approach...
Another thing I'd like to quote found at \"C2\" is a good example of what the broad interpretation of
\"MVC\" in fact allows is:
\"...Perhaps web pages are an example of this - with the 'view' being css, 'model' being
html, 'control' being, in part, the browser...\"
So what you can take fro here is that when moving from precise strict meaning of MVC to the
broad sense use of it, then certain (and quite large! ;) degree of vagueness, impreciseness and
confusion are in fact:
- inherent
- deliberate
- inevitable
In other words, the feelings that some people feel in association with \"MVC\" abbreviation are
\"perfectly normal\" in medical sense ;)
So, having cleared that and ruled out the personal \"insecurity complex\",
we can now relax a bit and \"let it go\" and accept the realities of the modern world...
Then, we can draw a conclusion that \"MVC\" (and in fact the \"Design Patterns\" in general) should
not even be attempted to be studied as the hard science i.e. as something inherently existing in
nature in some \"true form\", but more like linguistics and anthropology - i.e.
like things that are artificially coined by society and which evolve in certain way whether like it or
not...

(Another great example of similar kind of thing is the use of term and the concept of \"Architecture\"
and \"Architect\" these days in IT/SE/SD industry and which is causing a lot of controversy, but
that's a separate topic... ;)
[O.K. - however can't help some more off-topic note though: there is also an older and
somewhat similar controversy and confusion about \"Software Engineering\" and \"Software
Engineers\", like is Software Engineering really engineering or what is it etc -
But, you don't hear much of those sort of arguments these days - I think that's because it has
been satisfactorily solved by now by the following formula: \"Software Engineering is whatever
the Software Engineers do.(period!)\"
;]
So with this \"wisdom\" we can \"move on\" and accept the various broad meanings and
interpretations of \"MVC\". Try to keep it “open minded”.
------------------------------------------------------------------------------------------------------------------------------
So, essentially looks like there are three meanings of \"MVC\" (but again with various sub-
meanings inside each one! ;)
1. MVC - the actual UI framework in Smalltalk-80
2. \"classic\" MVC - most well described in POSA1 book (\"Pattern-Oriented Software
Architecture Volume 1: A System of Patterns\" – surely folks here know this book)
It is also mentioned in dozens of other (if not all) books on OO Design Patterns,
but usually as an example/application of an OBSERVER pattern (!!)
[including GoF, pp.4-5, p.303 ... \"known uses\" of Observer...]
So POSA1 is in fact one of the rare sources which clearly catalogues it as a \"architectural
pattern\" (and, yes - there are some somewhat rather more scholastic discussion whether MVC -
even in its \"classic\" meaning described here - whether MVC is a \"pattern\" or a \"composition of
patterns / compound pattern\" or an \"architecture\" or \"style\" or “approach”, “method”, “paradigm”
etc etc)
Now, when I was reading it in POSA1 I had some interesting \"subconscious\" feelings:
a feeling of low-level... \"mouse-click\"... \"key-pressed\"... \"draw\"... \"render text\"... (?!?!)
a feeling of a specific implementation solution imposed by whatever archaic platform
Smalltalk-80 was running on...
So interestingly, this somewhat relates again with MVC section in Fowler's
http://www.martinfowler.com/eaaDev/uiArchs.html
\"...
As we look at MVC it's important to remember that this was one of the first attempts to do
serious UI work on any kind of scale.
Graphical User Interfaces were not exactly common in the 70's. The Forms and Controls
model I've just described came after MVC -
I've described it first because it's simpler, not always in a good way. Again I'll discuss

Smalltalk 80's MVC using the assessment example - but
be aware that I am taking a few liberties with the actual details of Smalltalk 80 to do this -
for start it was monochrome system...
And again, as I said earlier M. Fowler goes into precise details describing the genuine original
\"True\" MVC… one more quote which I think is especially notable too
\"... At this point I should stress that there's not just one view and controller, you have a
view-controller pair for each element of the screen, each of the controls and the screen as
a whole. \"
This in fact coincides and matches very well the MVC design arrangement described (quite
decently and thoroughly) in POSA1and also as mentioned earlier the Fowler’s article then
explains how the realities are different these days and how most of widely-used UI
frameworks/technologies are not strictly speaking an MVC (WinForms, WebForms, all those other
“Forms” and “Pages” etc) and that most of nowadays rich-UI development paradigms can follow
better under Model-View-Presenter approach
Note that what is usually emphasized by \"MVC purists\" are the following two aspects of \"genuine\"
MVC:
- the aspect of the Controller (in fact MANY controllers, as in the above quote)
- the aspect of Observer
(many opinions in this regard can be found again on http://c2.com/cgi/wiki?ModelViewController)
POSA1 on another hand takes a bit more relaxed approach and allows more broad
interpretations thus allowing all of the GUI/Windowing frameworks (let’s focus on the non-Web
ones - they are separate story address below) to have their place under MVC as \"variants\"...
And the first thing that gets sacrificed is the presence of the Controller(s) as separate object(s):
“
…
Document-View
This variant relaxes the separation of view and
controller. In several GUI platforms, window display and event
handling are closely interwoven. For example, the X Window System
reports events relative to a window. You can combine the
responsibilities of the view and the controller from MVC in a single
component by sacrificing exchangeability of controllers. This kind of
structure is often called a Document-View architecture [App89],
[Gam91], [Kru96]. The document component corresponds to the
model in MVC, and also implements a change-propagation
mechanism. The view component of Document-View combines the
responsibilities of controller and view in MVC, and implements the
user interface of the system.
…”
So this explains why it is sometimes hard to see the MVC in where it is supposedly present - like
in some GUI framework you are using (again let's leave web-app ones aside for the moment...
because most of the time you are in fact using either something similar to Model-View-Presenter
or even most likely a Document-View one...
Interestingly many things which are very often quoted and strongly associated with MVC, are still
not MVC in strong sense…

The only one that comes somewhat especially (and deliberately) close to true MVC is Java's
Swing... but still there \"interesting\" subtleties...
From http://en.wikipedia.org/wiki/Model-view-controller
Java Swing
Java Swing is different from the other frameworks, in that it supports two MVC patterns.
Model (Frame level)
Like the other frameworks, the design of the real model is usually left to the developer.
Model (Control level)
Swing also supports models on the control level. Unlike other frameworks, Swing exposes the
internal storage of each control as a model.
[** O.K. comment: here I think Swing designers did a deliberate attempt to approximate the
original Smalltalk’s MVC]
View
The view is represented by a class that inherits from Component.
Controller
Java Swing doesn't necessarily use a single controller. Because its event model is based on
interfaces, it is common to create an anonymous action class for each event. In fact, the real
controller is in a separate thread. It catches and propagates the events to the view and
model.
This is also brings to mind the question most people have in regards to \"MVC\" –
\"but where's the Controller...?\"
(and sometimes the answer is in the realm of something like \"well... Controller is ... everything
else after you taken out the Model and the View...\" ;)
There is even an dedicated resource (again on C2 wiki) for this question:
http://c2.com/cgi/wiki?WhatsaControllerAnyway
Also an interesting point of discussion is the level at which MVC is to be considered?
Addressing the MODEL aspect on itself…
For example is the Model really something low level such as “the number representing
position of scrollbar” – an example often given as MVC example, especially in Swing
literature…
Or is Model really something at higher more conceptual level – ie.e Domain Model.
Looks like there is no strict consensus here either it is open for broad and flexible
interpretation.
----

But all for all, all these variations are still nevertheless reasonably close to the \"classic MVC\" and
for definition of \"classic MVC\" which I think it is sensible to accept the what’s given in POSA1
and all the variations it \"allows\"...
And one thing that is notably still present in all these variations is the use of classical OBSERVER
pattern in classical OO Design patterns sense...
This leads us to the most \"broad sense\" of the \"MVC\" acronym, which also lately happens to be
the prevailing use of it (due to Web-apps, \"J2EE\", “Ruby on Rails” etc)
3. \"Web MVC\" - basically the “classic MVC” has became more of \"METAPHOR\" in the
context of web-applications rather then something used in its original OOD sense...
On a web this metaphor stands for
an “architectural style” of separating presentation (\"view\") from the business data/logic
(\"model\")
or even for merely
\"... separating INPUT, PROCESSING and OUTPUT\"...
Most interestingly, the original strong association between MVC and OBSERVER pattern is totally
lost as the \"propagation mechanism\" has become a \"poll mechanism\" - i.e. refreshing the
browser (!!)
(AJAX might be altering this aspect a bit lately - although it still remains a POLL mechanism!...
but here we talk more about \"traditional\" \"Web-MVC\" - J2EE design blueprints, Struts etc... )
Some people think that to a great extent this \"MVC metaphor\" for web-apps was \"invented\" and
pushed and promoted by Sun/J2EE and its marketing forces... \"Model 1 and Model 2\",
\"blueprints\" etc…
Let’s reproduce again that quote from C2 wiki http://c2.com/cgi/wiki?ModelViewController
in it's entirety (emphasis added)
\"...When a system obeys the principle DoTheMostComplexThingThatCouldPossiblyWork,
marketects often respond by clumping its rambling notions together into 3 groups. The sub-
SpaghettiCode group nearest the User becomes the \"view\", that nearest the database becomes
the \"model\", and the stuff in between becomes the \"controller\".
Marketects then refer to their project's architecture as \"MVC\", borrowing that acronym's
impressive lineage.
Sounds like SunMicrosystems's JavaLanguage PetStore...\"
To some extent the Java/J2EE has restored some more credibility to the \"MVC\" term use
(but still in \"metaphorical\" sense, or if you prefer \"at a level of abstraction higher than the
OOD\" sense... this is not a quiet – I just made it up myself right now ;)
This took form in such reasonably successful efforts as
Struts,
and later on, JSF

But again I’d like to throw in some interesting excerpt from a Struts book emphasis added):
----------------------------------------------------
Jakarta Struts Cookbook By Bill Siggelkow
You often hear Struts referred to as a model-view-controller (MVC) framework for web applications. Struts can
help you build web applications that separate the data (model) from the presentation (view); however, Struts
doesn't provide a framework for the model.
Rather, it supports custom Actions which broker the interaction between the view and model.
...
Though Struts is referred to as an MVC framework for web applications, Struts doesn't attempt to provide the
model of that paradigm.
Struts provides only the bridge between the view and the model, Struts Actions. An Action shouldn't access the database;
an Action shouldn't need to know how the data is stored and accessed. Instead, an Action acts as a thin façade to your
business services, marshalling data from the view to the model and back. The following FAQ from the Struts web site puts
it quite succinctly:
Ideally, all the database access code should be encapsulated behind the business API classes, so Struts doesn't
know what persistence layer you are using (or even if there is a persistence layer). It passes a key or search
String and gets back a bean or collection of beans. This lets you use the same business API classes in other
environments, and lets you run unit tests against your business API outside of Struts or a HTTP environment.
While Struts does support the data-source element for configuring JDBC data sources, the Struts release notes state that
this element may not be supported in the future. According to the Struts documentation, you should use the data-source
element when you need to pass a javax.sql.DataSource to a legacy API. This results in a dependency between the
Action and the persistence layer as illustrated in
As a result of “Web MVC” trend, the latest of POSA series books - POSA4 (which largely revisits
most of POSA1 and POSA2 from the perspective of nowadays - i.e \"10 years after\"… but
wrapps it in a context of “distributed systems” ) and POSA5 have been reflecting this \"new reality\"
and \"legitimizes\" the de facto broad meaning of \"MVC\" term
-----------------------------------------------
POSA4
Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing
(Hardcover)
by Frank Buschmann (Author), Kevlin Henney (Author), Douglas C. Schmidt (Author)
p.188
Divide the interactive application into three decoupled parts:
processing, input and output. Ensure the consistency of the
three parts with the help of a change propagation mechanism.
...
A Model-View-Controller arrangement separates responsibilities of an
application that tend to change at a different rate, to support their
independent evolution.
---------------------------------------------
------------------------------------------------------------------------------------------------------------
POSA5
Model-View-
Controller (MVC)

The MODEL-VIEW-CONTROLLER pattern [POSA1] [POSA4] [Fow02] divides
an interactive application with respect to three roles. The model
contains the core functionality and data. Views display information to
the user. Controllers handle user input. Views and controllers together
comprise the user interface. A change-propagation mechanism ensures
consistency between the user interface and the model.
-----------------------------------------
I personally still however feel that in case of \"Web MVC\" a browser refresh is a bit of a stretch for
\"change propagation mechanism\"
(again, AJAX is altering the landscape somewhat but it is still a POLL mechanism !! ;)
So I guess we shall just accept this “high-abstraction-level” and decoupled from OOD meaning
of the “MVC” in case of “Web MVC”…
I guess on a Web the “Web MVC” is just as close approximation of the “MVC” metaphor as you
can get as is the iGoogle “desktop” (or whatever it’s called) an approximation of my real (office
furniture) desktop metaphor.. ;)
Basically we are dealing with a linguistic phenomenon where and old word “MVC” has
evolved to a substantially different NEW meaning…
---------------------------------------------------------------------------------------------------------------------------------
Questions for group discussion at UG meeting:
who used \"MVC\" in his/her design or thinks/knows that some framework been used is \"MVC\"?
(in ANY meaning of \"MVC\" !!)
is WinForm MVC? WebForms?
is Swing MVC ?
is AWT? SWT?
what about Delphi and alike?... VB?
3rd party \"rich-GUI-controls\" - DevExpress, Dundas etc?
what form did controller(s) take?
did you really use a separate object for controller? (probably not, as most platfomrs/frameworks
implement \"Document-View\" see POSA1 pp.140-141,143)
now to \"Web MVC\"
ASP.NET?
JSPs?
Struts?
JSF?
Ruby-On-Rails?

APPENDIX. Clippings and quotations from various books and sometimes links they give
Might use some of these for discussion purposes…
------------------------------------------------------------------------------------------------------------
POSA 4
p.174
... The Model-View-
Presenter [Fow06] is also related to Model-View-Controller,
but works better for rich client development than MVC because it
does not delegate all view behavior to the model. An intermediate
presenter component receives all user actions, such as when clicking
a checkbox, or if the involvement of the model is necessary, such as
when clicking an 'Apply' button, and decides whether it can handle
them without consulting the model. This improves composability of
complex views and the testability of the different roles.
[Fow06]
M. Fowler: The Model-View-Presenter Pattern,
http://martinfowler.com/eaaDev/ModelViewPresenter.html,
2006
M. FOWLER HAS \"RETIRED\" THIS RECENTLY - SPLIT INTO TWO OTHER THINGS...
http://geekswithblogs.net/billy/archive/2006/07/20/85815.aspx
http://www.darronschall.com/weblog/archives/000113.cfm
http://martinfowler.com/eaaDev/uiArchs.html
http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx
-----
http://www.codeproject.com/aspnet/ModelViewPresenter.asp
Model-View-Presenter
Model-View-Presenter (MVP) is a variation of the Model-View-Controller (MVC) pattern but
specifically geared towards a page event model such as ASP.NET. For a bit of history, MVP was
originally used as the framework of choice behind Dolphin Smalltalk. The primary differentiator of
MVP is that the Presenter implements an Observer design of MVC but the basic ideas of MVC
remain the same: the model stores the data, the view shows a representation of the model, and
the presenter coordinates communications between the layers. MVP implements an Observer
approach with respect to the fact that the Presenter interprets events and performs logic
necessary to map those events to the proper commands to manipulate the model. For more
reading on MVC vs. MVP, take a look at Darron Schall's concise entry on the subject. What
follows is a detailed examination of MVP in the form of three example projects.

Author's note: Martin Fowler has suggested that MVP be split between two \"new\" patterns called
Supervising Controller and Passive View. Go here for a very short synopsis of the split. The
content described herein is more consistent with Supervising Controller as the View is aware of
the Model.
---------------------------------------------------------------------------------------------------------------------------------
Refactoring: Improving the Design of Existing Code
Martin Fowler--
Whenever you hear people talking about objects, you hear about model-view-controller
(MVC). This idea underpinned the relationship between the graphical user interface (GUI)
and domain objects in Smalltalk-80.
The gold at the heart of MVC is the separation between the user interface code (the view,
these days often called the presentation) and the domain logic (the model). The presentation
classes contain only the logic needed to deal with the user interface. Domain objects contain
no visual code but all the business logic. This separates two complicated parts of the program
into pieces that are easier to modify. It also allows multiple presentations of the same
business logic. Those experienced in working with objects use this separation instinctively,
and it has proved its worth.
But this is not how most people who work with GUIs do their design. Most environments
with client-server GUIs use a logical two-tier design: the data sits in the database and the
logic sits in the presentation classes. The environment often forces you toward this style of
design, making it hard for you to put the logic anywhere else.
Java is a proper object-oriented environment, so you can create nonvisual domain objects
that contain business logic. However, you'll often come across code written in the two-tier
style.
---------------------------------------------------------------------------------------------------------------------------------
Thinking in C#
Larry O’Brien and Bruce Eckel
p.577
Model-View-Controller
Model-View-Controller, commonly referred to simply as “MVC,” was the first
widely known architectural pattern for decoupling the graphical user interface
from underlying application logic. Unfortunately, many people confuse MVC with
any architecture that separates presentation logic from domain logic. So when
someone starts talking about MVC, it’s wise to allow for quite a bit of imprecision.
In MVC, the Model encapsulates the system’s logical behavior and state, the View
requests and reflects that state on the display, and the Controller interprets lowlevel
inputs such as mouse and keyboard strokes, resulting in commands to either
the Model or the View.
MVC trades off a lot of static structure — the definition of objects for each of the
various responsibilities – for the advantage of being able to independently vary
the view and the controller. This is not much of an advantage in Windows
programs, where the view is always a bitmapped two-dimensional display and the
controller is always a combination of a keyboard and a mouse-like pointing
device. However, USB’s widespread support has already led to interesting new

controllers and the not-so-distant future will bring both voice and gesture control
and “hybrid reality” displays to seamlessly integrate computer-generated data
into real vision (e.g., glasses that superimpose arrows and labels on reality). If
you happen to be lucky enough to be working with such advanced technologies,
MVC may be just the thing. Even if not, it’s worth discussing briefly as an
example of decoupling GUI concerns taken to the logical extreme. In our
example, our domain state is simply an array of Boolean values; we want the
display to show these values as buttons and display, in the title bar, whether all
the values are true or whether some are false:
...
p.581
The clear delineation of duties in MVC is appealing – the View passively reflects
the Model, the Controller mediates updates, and the Model is responsible
only for itself. You can have many View classes that reflect the same Model (say,
one showing a graph of values, the other showing a list) and dynamically switch
between them. However, the structural complexity of MVC is a considerable
burden and is difficult to “integrate” with the Visual Designer tool.
------------------------------------------------------------------------------------------------------------
Java Swing
Copyright © 1998 O'Reilly & Associates, Inc. All rights reserved.
p.22
1.4 The Model-View-Controller Architecture
Swing uses the model-view-controller architecture (MVC) as the fundamental design behind each
of its components. Essentially, MVC breaks GUI components into three elements. Each of these
elements plays a crucial role in how the component behaves.
...
p.23
1.4 The Model-View-Controller Architecture
Swing uses the model-view-controller architecture (MVC) as the fundamental design behind each
of its components. Essentially, MVC breaks GUI components into three elements. Each of these
elements plays a crucial role in how the component behaves.
----------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------
Java™ Design Patterns: A Tutorial
By James W. Cooper
Publisher : Addison Wesley
Pub Date : January 28, 2000
ISBN: 0-201-48539-7
Pages : 352
The MVC Architecture as an Observer
As we noted in Chapter 3, the JList, JTable, and JTree objects all
operate as observers of a data model. In fact, all of the visual components
derived from JComponent can have this same division of labor between the
data and the visual representation. In JFC parlance, this is referred to as the
Model-View-Controller (MVC) architecture, where the data are represented
by the Model, and the View by the visual component. The Controller is the
communication between the Model and View objects, and may be a separate
class or it may be inherent in either the model or the view. This is the case for
the JFC components, and they are all examples of the Observer pattern we’ve
just been discussing.
----------------------------------------------------------------------------------------------------------------
Natalie Levi with Philip Heller Java ™
2: Web Developer Certification Study Guide
A project’s success is often measured by its immediate return value, and its
future ability to expand, change, be maintained, and adapt. Most applications
should be written with extensibility in mind; this means changes or
additions do not break existing components. The Model View Controller
design pattern is geared toward creating an application that can increase
client-side functionality without warranting changes to the server-side code.
The pattern was originally developed by using the language SmallTalk
and later gained popularity in the Java market through its extensive use
within the Swing component library. The pattern takes a single graphical
object and breaks down its tasks into three pieces:
_ The controller, which triggers a change to the component
_ The model, which manages the data by providing methods to alter or
access the information
_ The view, which provides a visual display of the current data
A scrollbar component is a perfect example of MVC in action. It has a few
controllers, both up and down buttons, plus the slider. When any of these
elements is used, the controller invokes the model. The data associated with
a scrollbar is usually an int value that represents the location of the slider.
The up-arrow controller tells the model to increase the int value, and the
down-arrow controller calls the model’s method to decrease the value. It is
then the model’s responsibility to update the data and notify listeners or
views interested in the recently changed data. Figure 11.8 provides a visual
representation of each MVC component within a scrollbar.
FIGURE 1 1 . 8 MVC within a scrollbar
Model
int value = 1;
View
Controller Controller
Model View Controller Pattern 439
The class that handles the visual presentation is notified of a change and is

able to repaint the image to correctly represent the current data. In this case,
the slider would be repositioned to represent the increase or decrease in value.
The benefits you gain from creating three classes, rather than two or one,
are as follows:
_ Changes to the controller do not affect any view classes.
_ Changes to the view do not affect any controller classes.
_ You can add additional view or controller classes without affecting
existing code.
By removing the data from the graphical components and by separating
these components into two categories, one that controls and one that displays,
you create an application environment that is easily extensible.
The order of operations is as follows:
1. When the controller is triggered, it communicates a change to the
model.
2. The model makes a change to the data and pushes the new data to the
appropriate views.
3. The view receives the new data and displays the new image or form.
------------------------------------------------------------------------------------------------------------
Learning Java
Pat Niemeyer
Jonathan Knudsen
Publisher: O'Reilly
First Edition May 2000
ISBN: 1-56592-718-4, 722 pages
Before continuing our discussion of GUI concepts, we want to make a brief aside and talk
about the Model/View/Controller (MVC) framework. MVC is a method of building reusable
components that logically separates the structure, presentation, and behavior of a component
into separate pieces. MVC is primarily concerned with building user interface components,
but the basic ideas can be applied to many design issues; its principles can be seen throughout
Java.
The fundamental idea behind MVC is the separation of the data model for an item from its
presentation. For example, we can draw different representations (e.g., bar graphs, pie charts)
of the data in a spreadsheet. The data is the model ; the particular representation is the view . A
single model can have many views that present the data differently. A user interface
component's controller defines and governs its behavior. Typically, this includes changes to
the model, which, in turn, cause the view(s) to change, also. For a checkbox component, the
data model could be a single boolean variable, indicating whether it's checked or not. The
behavior for handling mouse-press events would alter the model, and the view would examine
that data when it draws the on-screen representation.
The way in which Swing objects communicate, by passing events from sources to listeners, is
part of this MVC concept of separation. Event listeners are \"observers\" (controllers) and event
sources are \"observables\" (models). When an observable changes or performs a function, it
notifies all of its observers of the activity.
Swing components explicitly support MVC. Each component is actually composed of two
pieces. One piece, called the UI-delegate, is responsible for the \"view\" and \"controller\" roles.
It takes care of drawing the component and responding to user events. The second piece is the
data model itself. This separation makes it possible for multiple Swing components to share a
single data model. For example, a read-only text box and a drop-down list box could use the
same list of strings as a data model.

15.1 Text Components
Swing gives us sophisticated text components, from plain text entry boxes to HTML interpreters.
For
full coverage of Swing's text capabilities, see Java Swing, by Robert Eckstein, Marc Loy, and
Dave
Wood (O'Reilly & Associates). In that encyclopedic book, six meaty chapters are devoted to text.
It's
a huge subject; we'll just scratch the surface here.
Let's begin by examining the simpler text components: JTextArea is a multiline text editor;
JTextField is a simple, single-line text editor. Both JTextField and JTextArea derive from
the JTextComponent class, which provides the functionality they have in common. This includes
methods for setting and retrieving the displayed text, specifying whether the text is \"editable\" or
read-only, manipulating the cursor position within the text, and manipulating text selections.
Observing changes in text components requires an understanding of how the components
implement
the Model-View-Controller (MVC) architecture. You may recall from the last chapter that Swing
components implement a true MVC architecture. It's in the text components that you first get an
inkling of a clear separation between the M and VC parts of the MVC architecture. The model for
text components is an object called a Document. When you add or remove text from a
JTextField or a JTextArea, the corresponding Document is changed. It's the document itself,
not the visual components, that generates text events when something changes. To receive
notification of JTextArea changes, therefore, you register with the underlying Document, not
with the JTextArea component itself:
JTextArea textArea = new JTextArea( );
Document d = textArea.getDocument( );
d.addDocumentListener(someListener);
As you'll see in an upcoming example, you can easily have more than one visual text component
use
the same underlying data model, or Document.
In addition, JTextField components generate an ActionEvent whenever the user presses the
Return key within the field. To get these events, implement the ActionListener interface, and
call addActionListener( ) to register.
Model-View-Controller (MVC) framework
A user-interface design that originated in Smalltalk. In MVC, the data for a display
item is called the \"model.\" A \"view\" displays a particular representation of the model,
and a \"controller\" provides user interaction with both. Java incorporates many MVC
concepts
The Model-View-Controller
Paradigm
Many GUI toolkits (aside from visual tools like Visual Basic or Powerbuilder)
partition the classes into user interface and application data classes. (These are
sometimes referred to as the presentation and logic layers.) Smalltalk-80 bestowed
upon us the Model/View/Controller (MVC) architecture for presentation and logic
layers. MVC refines the idea of presentation and logic layers by introducing another
partition. An MVC triad consists of cooperating objects: the Model, the View, and
the Controller. The Controller and View are typically user interface objects. The
Controller allows a user to modify the Model. Once modified, the Model notifies the
View that a change has occurred. The View queries the Model and displays the
updated information. By separating the objects this way, the interactions are greatly
simplified, the coupling is reduced, and the responsibilities of each object are very
clear. The Model never has a user interface component. The View never changes the

Model. The Controller never directly interacts with the View. Figure 23.9 shows the
connections in an application with one Model, two Views, and two Controllers. You
can see that the upper half of the figure looks just like the connections between an
Observable and two Observers. Of course, that is hardly a coincidence. In
many ways, you can consider MVC as one of the earliest occurrences of the
Observer pattern.
Figure 23.9: An example of a Model-View-Controller architecture.
Although Java does not directly refer to MVC, the built-in Observer mechanism
forms the foundation upon which you can build MVC applications. Java applications
built with an MVC architecture evolve well over time. They can easily adopt new
interfaces, new models, and new displays. Ideally, each component of MVC can be
replaced or reused independently of the whole.
--------------------------------------------------------------------------------------
---------------------------------------------------------------------------
Java Concurrency in Practice
By Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea
...............................................
Publisher: Addison Wesley Professional
Pub Date: May 09, 2006
Print ISBN-10: 0-321-34960-1
Print ISBN-13: 978-0-321-34960-6
Pages: 384
9.1. Why are GUIs Single-threaded?
In the old days, GUI applications were single-threaded and GUI events were processed from a
\"main event loop\". Modern GUI frameworks use a model that is only slightly different: they
create a dedicated event dispatch thread (EDT) for handling GUI events.
Single-threaded GUI frameworks are not unique to Java; Qt, NextStep, MacOS Cocoa, X
Windows, and many others are also single-threaded. This is not for lack of trying; there have
149
been many attempts to write multithreaded GUI frameworks, but because of persistent problems
with race conditions and deadlock, they all eventually arrived at the single-threaded event queue
model in which a dedicated thread fetches events off a queue and dispatches them to
applicationdefined event handlers. (AWT originally tried to support a greater degree of
multithreaded access, and the decision to make Swing single-threaded was based largely on
experience with AWT.)
Multithreaded GUI frameworks tend to be particularly susceptible to deadlock, partially because
of the unfortunate interaction between input event processing and any sensible object-oriented
modeling of GUI components. Actions initiated by the user tend to \"bubble up\" from the OS to
the applicationa mouse click is detected by the OS, is turned into a \"mouse click\" event by the
toolkit, and is eventually delivered to an application listener as a higher level event such as a
\"button pressed\" event. On the other hand, application-initiated actions \"bubble down\" from the
application to the OSchanging the background color of a component originates in the application
and is dispatched to a specific component class and eventually into the OS for rendering.
Combining this tendency for activities to access the same GUI objects in the opposite order with
the requirement of making each object thread-safe yields a recipe for inconsistent lock ordering,
which leads to deadlock (see Chapter 10). And this is exactly what nearly every GUI toolkit
development effort rediscovered through experience.

Another factor leading to deadlock in multithreaded GUI frameworks is the prevalence of the
model-view-control (MVC) pattern. Factoring user interactions into cooperating model, view,
and controller objects greatly simplifies implementing GUI applications, but again raises the risk
of inconsistent lock ordering. The controller calls into the model, which notifies the view that
something has changed. But the controller can also call into the view, which may in turn call
back into the model to query the model state. The result is again inconsistent lock ordering, with
the attendant risk of deadlock.
In his weblog,[1] Sun VP Graham Hamilton nicely sums up the challenges, describing why the
multithreaded GUI toolkit is one of the recurring \"failed dreams\" of computer science.
[1] http://weblogs.java.net/blog/kgh/archive/2004/10
I believe you can program successfully with multithreaded GUI toolkits if the toolkit is very
carefully designed; if the toolkit exposes its locking methodology in gory detail; if you are very
smart, very careful, and have a global understanding of the whole structure of the toolkit. If you
get one of these things slightly wrong, things will mostly work, but you will get occasional hangs
(due to deadlocks) or glitches (due to races). This multithreaded approach works best for people
who have been intimately involved in the design of the toolkit.
Unfortunately, I don't think this set of characteristics scales to widespread commercial use. What
you tend to end up with is normal smart programmers building apps that don't quite work
reliably for reasons that are not at all obvious. So the authors get very disgruntled and frustrated
and use bad words on the poor innocent toolkit.
Single-threaded GUI frameworks achieve thread safety via thread confinement; all GUI objects,
including visual components and data models, are accessed exclusively from the event thread. Of
course, this just pushes some of the thread safety burden back onto the application developer,
who must make sure these objects are properly confined.
---------------------------------------------------------------------------
“Web MVC”
--------------------------------
Excerpted from: Core Servlets and JavaServer Pages, Vol. 1: Core Technologies,
Second Edition by Marty Hall, Larry Brown
MVC Frameworks
The key motivation behind the MVC approach is the desire to separate the code that
creates and manipulates the data from the code that presents the data. The basic
tools needed to implement this presentation-layer separation are standard in the
Simple application or
small development team.
Complex application or
large development team.
• Call Java code directly. Place all Java code in JSP page.
Appropriate only for very small amounts of code. Chapter 11.
• Call Java code indirectly. Develop separate utility classes.
Insert into JSP page only the Java code needed to invoke the
utility classes. Chapter 11.
• Use beans. Develop separate utility classes structured as
beans. Use jsp:useBean, jsp:getProperty, and
jsp:setProperty to invoke the code. Chapter 14

• Use the MVC architecture. Have a servlet respond to
original request, look up data, and store results in beans.
Forward to a JSP page to present results. JSP page uses beans.
This chapter.
• Use the JSP expression language. Use shorthand syntax to
access and output object properties. Usually used in
conjunction with beans and MVC. Chapter 16.
• Use custom tags. Develop tag handler classes. Invoke the tag
handlers with XML-like custom tags. Volume 2.
15.2 Implementing MVC with RequestDispatcher 437
servlet API and are the topic of this chapter. However, in very complex applications,
a more elaborate MVC framework is sometimes beneficial. The most popular of
these frameworks is Apache Struts; it is discussed at length in Volume 2 of this book.
Although Struts is useful and widely used, you should not feel that you must use
Struts in order to apply the MVC approach. For simple and moderately complex
applications, implementing MVC from scratch with RequestDispatcher is
straightforward and flexible. Do not be intimidated: go ahead and start with the basic
approach. In many situations, you will stick with the basic approach for the entire life
of your application. Even if you decide to use Struts or another MVC framework
later, you will recoup much of your investment because most of your work will also
apply to the elaborate frameworks.
Architecture or Approach?
The term “architecture” often connotes “overall system design.” Although many systems
are indeed designed with MVC at their core, it is not necessary to redesign your
overall system just to make use of the MVC approach. Not at all. It is quite common
for applications to handle some requests with servlets, other requests with JSP pages,
and still others with servlets and JSP acting in conjunction as described in this chapter.
Do not feel that you have to rework your entire system architecture just to use
the MVC approach: go ahead and start applying it in the parts of your application
where it fits best.
-----------------------------------------------------------------------------------------------------------------------------
Designing Enterprise Applications
with the J2EETM Platform, Second Edition
Inderjeet Singh, Beth Stearns,
Mark Johnson, and the Enterprise Team
4.4 Web-Tier Application Framework Design
Model-View-Controller (“MVC”) is the BluePrints recommended architectural
design pattern for interactive applications. MVC, described in Chapter 11, organizes
an interactive application into three separate modules: one for the application model
with its data representation and business logic, the second for views that provide
data presentation and user input, and the third for a controller to dispatch requests
and control flow. Most Web-tier application frameworks use some variation of the
MVC design pattern.
The MVC design pattern provides a host of design benefits. MVC separates
design concerns (data persistence and behavior, presentation, and control),
decreasing code duplication, centralizing control, and making the application more
easily modifiable. MVC also helps developers with different skill sets to focus on

their core skills and collaborate through clearly defined interfaces. For example, a
J2EE application project may include developers of custom tags, views, applica-
WEB-TIER APPLICATION FRAMEWORK DESIGN 95
tion logic, database functionality, and networking. An MVC design can centralize
control of such application facilities as security, logging, and screen flow. New
data sources are easy to add to an MVC application by creating code that adapts
the new data source to the view API. Similarly, new client types are easy to add by
adapting the new client type to operate as an MVC view. MVC clearly defines the
responsibilities of participating classes, making bugs easier to track down and
eliminate.
This section describes how to use MVC to organize a J2EE Web application
design using the sample application’s Web Application Framework design as an
example. Many of the key classes described (the controller, the templating service,
the abstract action class, and so on) are usable for any application, not just for an
online shopping application.
A J2EE application’s Web tier serves HTTP requests. At the highest level, the
Web tier does four basic things in a specific order: interprets client requests, dispatches
those requests to business logic, selects the next view for display, and generates
and delivers the next view. (See Figure 4.2.)
The Web-tier controller receives each incoming HTTP request and invokes
the requested business logic operation in the application model. Based on the
results of the operation and state of the model, the controller then selects the next
view to display. Finally, the controller generates the selected view and transmits it
to the client for presentation.
Figure 4.2 is deceptively simple. An enterprise application’s Web tier commonly
has the following requirements:
The Web-tier controller receives each incoming HTTP request and invokes
the requested business logic operation in the application model. Based on the
results of the operation and state of the model, the controller then selects the next
view to display. Finally, the controller generates the selected view and transmits it
to the client for presentation.
Figure 4.2 is deceptively simple. An enterprise application’s Web tier commonly
has the following requirements:
96 CHAPTER 4 THE WEB TIER
• An application design must have a strategy for serving current and future client
types.
• A Web-tier controller must be maintainable and extensible. Its tasks include
mapping requests to application model operations, selecting and assembling
views, and managing screen flow. Good structure can minimize code complexity.
• Application model API design and technology selection have important implications
for an application’s complexity, scalability, and software quality.
• Choosing an appropriate technology for generating dynamic content improves
development and maintenance efficiency.
The BluePrints best practice is to implement the Web tier of a J2EE enterprise
application using an appropriate Web application framework. (See Section 4.4.5
on page 114.) The next several sections describe the general design of a J2EE
application Web tier. If you choose to use a Web application framework, the following
discussion will help you to understand what the framework does and how
to use it. If you write your own Web-tier architectural code, the following design

discussions will help you make educated decisions about how to use the technology.
4.4.1 Structuring the Web Tier
Overall structure is the most important consideration in a Web-tier design. Both the
sample application and the various existingWeb application frameworks implement
some form of “Model 2” architecture, where a servlet manages client communication
and business logic execution, and presentation resides mainly in JSP pages.
The literature on Web-tier technology in the J2EE platform frequently uses
the terms “Model 1” and “Model 2” without explanation. This terminology stems
from early drafts of the JSP specification, which described two basic usage patterns
for JSP pages. While the terms have disappeared from the specification document,
they remain in common use. Model 1 and Model 2 simply refer to the
absence or presence (respectively) of a controller servlet that dispatches requests
from the client tier and selects views.
A Model 1 architecture consists of a Web browser directly accessing Web-tier
JSP pages. The JSP pages access Web-tier JavaBeans that represent the application
model, and the next view to display (JSP page, servlet, HTML page, and so
on) is determined either by hyperlinks selected in the source document or by
WEB-TIER APPLICATION FRAMEWORK DESIGN 97
request parameters. A Model 1 application control is decentralized, because the
current page being displayed determines the next page to display. In addition, each
JSP page or servlet processes its own inputs (parameters from GET or POST). In
some Model 1 architectures, choosing the next page to display occurs in scriptlet
code, but this usage is considered poor form. (See the design guideline Section
4.2.6.8 on page 89.)
A Model 2 architecture introduces a controller servlet between the browser
and the JSP pages or servlet content being delivered. The controller centralizes the
logic for dispatching requests to the next view based on the request URL, input
parameters, and application state. The controller also handles view selection,
which decouples JSP pages and servlets from one another. Model 2 applications
are easier to maintain and extend, because views do not refer to each other
directly. The Model 2 controller servlet provides a single point of control for security
and logging, and often encapsulates incoming data into a form usable by the
back-end MVC model. For these reasons, the Model 2 architecture is recommended
for most interactive applications.
An MVC application framework can greatly simplify implementing a Model
2 application. Application frameworks such as Apache Struts and JavaServer
FacesTM (see Section 4.4.5 on page 114) include a configurable front controller
servlet, and provide abstract classes that can be extended to handle request dispatches.
Some frameworks include macro languages or other tools that simplify
application construction.
The Model 1 architecture can provide a more lightweight design for small,
static applications. Model 1 architecture is suitable for applications that have very
simple page flow, have little need for centralized security control or logging, and
change little over time. Model 1 applications can often be refactored to Model 2
when application requirements change.
4.4.1.0.1 When to Switch from Model 1 to Model 2
JSP pages in a Model 1 application that use scripting elements, custom tags, or
JavaScript to forward requests should be refactored to Model 2.
A Model 1 architecture is best when the page navigation is simple and fixed,
and when a simple directory structure can represent the structure of the pages in
the application. Such applications usually embed the page flow information in the
links between the pages. The presence of forward in a JSP page implies that logic
embedded in the page is making a decision about the next page to display.
Over time, as the application grows and changes, page flow logic accumulates.
The application becomes difficult to maintain because the page flow logic is
98 CHAPTER 4 THE WEB TIER

distributed across multiple pages. The best time to switch from Model 1 to Model
2 is before this maintenance problem arises. This is why it’s usually best to choose
Model 2 from the outset, basing the application on an existing Web controller
framework that best meets application requirements. Model 1 remains a viable
option for simple, static applications.
4.4.2 Web-Tier MVC Controller Design
The Model 2 architecture uses servlets for processing requests and selecting views.
The Front Controller architectural design pattern centralizes an application’s request
processing and view selection in a single component. Each type ofWeb client sends
requests to and receives responses from a single URL, simplifying client development.
The Front Controller receives requests from the client and dispatches them to
the application model. This single point of dispatch makes the Front Controller a
logical place for such global facilities as security and logging. The Front Controller
also selects and formats the next client view. The controller is also an application of
the Mediator pattern, because it decouples view components from one another.
In the J2EE platform, a Front Controller is typically implemented as a servlet.
The sample application’s Front Controller servlet handles all HTTP requests. The
user views, discussed in the next section, are mostly JSP pages chosen by the
Front Controller.
4.4.2.1 Web-Tier Controller Design
A Web-tier MVC controller maps incoming requests to operations on the application
model, and selects views based on model and session state.Web-tier controllers
have a lot of duties, so they require careful design to manage complexity. Because
most enterprise applications grow over time, extensibility is an important requirement.
This section describes some strategies for the internal structure of a controller
in the Web tier, illustrated by example code adapted from the Web Application
Framework, part of the BluePrints sample application.
4.4.2.1.1 Identifying the Operation to Perform
When a controller receives an HTTP request, it needs to be able to distinguish what
application operation is being requested. How can the client, for example, request
WEB-TIER APPLICATION FRAMEWORK DESIGN 99
that the server create a new user? There are several ways to indicate to the server
which operation to perform. The more common methods include:
• Indicate the operation in a hidden form field, which a POST operation delivers
to the controller; for example:
<FORM METHOD=\"POST\" ACTION=\"http://myServer/myApp/myServlet\">
<INPUT TYPE=\"HIDDEN\" NAME=\"OP\" VALUE=\"createUser\"/>
<!-- other form contents... -->
</FORM>
• Indicate the operation in a HTTP GET query string parameter; for example:
http://myHost/myApp/servlets/myServlet?op=createUser
• Use a servlet mapping to map all URLs with a particular suffix or base URL to
a specific servlet. A servlet mapping is a deployment descriptor definition that
compares request paths to a pattern and dispatches matching requests to the
corresponding servlet. For example, imagine that a Web application’s deployment
descriptor defines the following servlet mapping:
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
Imagine also that the servlet’s context path is http://myServer/myApp/servlets.
The servlet container would direct a request with URL http://myServer/
myApp/createUser.do myServlet to myServlet, because the request URL
matches the pattern *.do. Servlet myServlet can extract the requested operation’s
name from the request URL. Chapter 11 of the Java Servlet 2.3 specification
defines servlet mappings.

Of the three options discussed here, the BluePrints recommendation is to use
servlet mappings when they are available. Servlet mappings provide the most flexible
way to control where to route URLs based on patterns in the URLs. Most
Web application frameworks (see Section 4.4.5 on page 114) use servlet mappings
to direct requests to the appropriate front controller for an application.
The sample application uses a servlet mapping to handle request URLs. The
servlet container maps all request URLs matching *.do to the main Web-tier con-
100 CHAPTER 4 THE WEB TIER
troller servlet, MainServlet.java. Another servlet mapping routes all URLs
matching *.screen to the templating service, which assembles composite views.
4.4.2.1.2 Invoking Model Methods
Once the controller has determined which operation to perform, it must invoke the
corresponding application model method with parameters derived from the request.
A naive controller design might use a large if-then-else statement, as shown in