🚀 go-pugleaf

�� ��������ת���� SE ������ ��
�� ԭ���� hoopdream ��� ��

from www.java.net
Beyond MVC: A New Look at the Servlet Infrastructure
by N. Alex Rupp
12/11/2003
This article is the first of two that examine in depth the origins of the Mo
del-View-Controller (MVC) design pattern and its misapplication to servlet f
ramework architectures. The purpose of this first piece is threefold. First,
 it attempts to provide an accurate description of the problems brought abou
t by MVC in servlet middleware. Second, it suggests techniques and strategie
s for coming up with a new design, one better suited to the needs of servlet
 infrastructure developers. Third, it offers an example of a completely new,
 nonderivative pattern we might use moving forward. The second article backs
 up my assertions by introducing and exploring a reference implementation of
 the new design.
Ultimately, my goal with these two articles is to convince the servlet middl
eware community once and for all to put the dark days of MVC behind us and t
o lay the groundwork for completely new, nonderivative servlet middleware ar
chitectures that better address our common needs. Please bear with me; I wou
ldn't write a piece about MVC in the servlet tier unless I believed it was a
 funeral dirge.
Part One: History of the MVC Pattern
We begin with a historical account of MVC's origins in the early 1970s and i
ts subsequent use as a pattern for thick-client UI component frameworks.
Tracing the historical origins of the Model-View-Controller pattern is not a
 difficult thing to do. The man who brought us MVC has published historical 
documents that date back to 1973, when object-oriented programming was still
 being conceived and scientists were only beginning to explore the concepts 
of "distributed, communicating components." (See Reenskaug, Trygve, "The His
tory of MVC.")
Following the paper trail back to the early days of object modeling is instr
uctional in two ways. First, it serves as a reminder that the problems we fa
ce today in distributed computing are by and large the same ones faced by co
mputer scientists from three decades ago �� in other words, the proverbial w
heel is still in dire need of reinvention. Second, it shows us how much we s
till have to learn about simplifying complex systems.
Oslo Norway, 1973
In August of 1973, Dr. Trygve Reenskaug, while working for the Central Insti
tute for Industrial Research in Oslo Norway, wrote a paper called "Administr
ative Control in the Shipyard," which he presented at the first Internationa
l Conference on Computing Applications in Shipbuilding that autumn. In his p
aper, Reenskaug analyzed the modern shipyard as an information system. In th
is exercise, he identified many of the technical and social complexities inh
erent in shipyards and suggested several techniques that could be used while
 describing the system. His goal was to reduce the overall complexity so the
 shipyard could be more easily modeled in a computer application.
If the goal of a component framework is to reduce complexity for developers 
modeling an information system, what strategies can the framework designer u
se to make this possible? Early on, Reenskaug touches upon the idea of "dist
ributed, communicating components." His strategy is that the "total system w
ill be decomposed into a number of components" (emphasis his; see Reenskaug,
 Trygve, "Administrative Control in the Shipyard"). Decomposition of a large
 or complex system into modular components played a central role in his stra
tegy. By now, most of us understand this concept very well. We call it the "
Separation of Concerns" of architectural components.
Following this strategy, Reenskaug begins to describe "a general framework" 
whose "main purpose is to enable us to mold a new information system to fit 
an existing way of organizing things, the resulting system being sufficientl
y flexible to be easily adapted to changes in the organization." (ibid.; emp
hasis mine.)
He then outlined several "major requirements [of] systems developed within t
he framework." (ibid) The following behaviors are those that the framework s
hould seek to enable:
We want to build man-machine systems. Manual override on automatically produ
ced results must be a routine matter, and the systems must be able to comput
e the consequences of such overrides.
Responsibility, authority, and competence will be spread out among groups of
 people in the shipyard. Our total data processing system must be divided in
to subsystems that are attached to the various areas of responsibility. The 
subsystems shall be controlled by these groups and further developed by them
.
A subsystem must be transparent to its responsibility group, so that its own
ers may fully understand their system's behavior.
All subsystems must be open-ended, so that they may be attached to other sub
systems belonging to the same or other responsibility groups.
The total system must be capable of continuous growth; it must be possible t
o add new subsystems or change old ones without disturbing the total system.
 It must be possible to include "foreign" systems developed by other people 
without upsetting the total system. The painful transition from one "generat
ion" to the next can no longer be tolerated. (ibid.)
A condensed list of these requirements would read:
Simplified manual override.
Divisible into modular subsystems.
Behavioral transparency of subsystems.
Subsystem modules are pluggable.
The total system is capable of continuous growth.
Despite the solid foundation that Dr. Reenskaug had laid out for implementin
g his framework, the lack of an object-oriented programming language stalled
 progress on what was to become MVC. It wasn't until several years later, in
 California, that he got access to the world's "first personal computer, the
 ALTO, with its powerful direct manipulation interfaces." It was at this tim
e that he began experimenting "with tools for end users manipulating their p
art of a total plan." (see "The History of MVC")
Xerox Palo Alto Research Center, 1978
This experimentation took place at the Xerox Palo Alto Research Center (PARC
). Access to the ALTO helped Dr. Reenskaug identify the end user of a distri
buted system. Dr. Reenskaug and his colleagues devised "MVC as a solution to
 controlling a large and complex data set." Their task was similar to the ta
sk he'd defined for the component framework in 1973 �� to reduce the complex
ity inherent in presenting an interface to the system. This time, the "subsy
stem" was actually the user interface.
Describing a new framework for accomplishing this task was not easy �� it ne
ver is. "The hardest part was to hit upon good names for the different archi
tectural components," Reenskaug writes. "Model-View-Editor was the first set
," In his "Thing-Model-View-Editor" paper (see Reenskaug, Trygve, "Thing-Mod
el-View-Editor"), Dr. Reenskaug defines the following terms:
Thing: "Something that is of interest to the user." (A real-world concept.)
Model: "An active representation of an abstraction in the form of data in a 
computing system." (Abstraction of the Thing.)
View: "One or more pictorial representations of the model."
Editor: "An interface between a user and one or more Views." (Later called "
Controller" and "Tool.")
Out of these early prototypes, MVC Triads emerged in SmallTalk-80. The model
 was an abstraction of the real-world concept, the view was its visual repre
sentation, and the controller was the buttons and slider bars that allowed t
he user to interact with it (thereby "controlling" the view). All pieces in 
the triad were interconnected and could communicate with the other two piece
s, so there was no layering or abstraction involved. Since then, Reenskaug h
as "preferred to use the term Tool rather then Controller." According to his
 notes, these are the terms he has used in later implementations (see "The H
istory of MVC")
Shortly thereafter, Dr. Reenskaug left the PARC laboratories and his work wa
s carried on by Jim Althoff and Dan Ingalls. Because of this early work, UI 
Development in ST-80 was greatly simplified, and the MVC pattern continues t
o this day to be an effective and appropriate solution for the design of use
r interface components.
MVC Pattern Language
It is important while we are studying and using MVC that we bear in mind the
 original purpose of the pattern: to reduce the complexity of user interface
s for a large and complex information system. It was designed for a specific
 purpose and evolved to meet a specific need.
Dr. Reenskaug's work in MVC has not been abandoned. Earlier this year, he be
gan publishing material on his new MVC pattern language.
Nowhere, ever, in any of his papers was it suggested that the MVC pattern co
uld be used to address the needs of n-tiered workflow processing infrastruct
ures. But here we are, 24 years later, trying to pound in nails with a screw
driver. Despite the careful effort of scientists from Reenskaug's generation
, it seems that we've not learned a thing.
Part Two: The Servlet Framework Antipattern
At this point, we're going to try to break through the recent buzz surroundi
ng the MVC pattern and illustrate how, despite its success in traditional UI
 frameworks, MVC fails to address the needs of servlet framework architectur
es and the framework development community.
But before we go any further, I'd like to define the terms "pattern" and "an
tipattern," so that the reader understands the context in which I'm using th
em throughout the remainder of the article. I borrow my definitions from the
 book AntiPatterns and Patterns in Software Configuration Management by Brow
n, McCormack, and Thomas.
"A Pattern is a form of solution intended to address a problem. The problem 
for Pattern readers has always been to identify when and how a Pattern shoul
d be used."
An AntiPattern is defined as "a commonly occurring solution to a problem tha
t generates decidedly negative consequences;" in other words, an AntiPattern
 is generally a commonly repeated practice in industry that is flawed in som
e manner and causes symptoms that are more undesirable than whatever positiv
e results were sought.
Design patterns can become dangerous in a development community when their p
opularity eclipses their ability to address the evolving needs of a developm
ent effort. By implementing patterns for their own sake, without a critical 
evaluation of their ability to describe the practical concerns of an informa
tion system, we contribute to the spread of antipatterns in our development 
community.
Some antipatterns are easy to identify and with a little effort can be easil
y avoided. However, some are not. At first blush, many antipatterns are indi
stinguishable from beneficial design patterns. They spread by giving us a se
nse of security and confidence in their use. By reducing them to advertising
 buzzwords, we re-enforce the perception that they are widely accepted, addr
ess a common problem, or confer some predictable advantage, outside of the c
ontext of their original use. There are no "one-size-fits-all" solutions whe
n it comes to information system design. A pattern might confer advantages w
ithin a given context, but outside of that context, all bets are off.
To make matters worse, technical, economic, and social circumstances can als
o contribute to the "silver bullet" mentality surrounding the antipattern, f
urther contributing to its popularity in the community. The inevitable resul
ting misapplication of the antipattern can introduce new complexities into o
ur software and conflict into our community.
Pressure (whether real or imagined) to conform to the antipattern is often g
reater than the technical or economic need to abandon the practice �� at lea
st in the short term. Time lends a different perspective to matters, however
, as what Reenskaug described as "the painful transition from one 'generatio
n' to the next" becomes incrementally more difficult to avoid.
Unwieldy, Inflexible Architectures
Although the Model-View-Controller design has proven itself throughout the y
ears to be an appropriate and beneficial pattern for modeling user-interface
 components, its use in designing distributed servlet infrastructures has le
d to very unfortunate results. Among these are the advancement of unwieldy, 
inflexible architectures that are incapable of being quickly altered to supp
ort the ever-changing demands of the technological and economic environment.

On October 19th, 2003, on the Struts development list, a user suggested the 
addition of a feature his business had found lacking from the framework. His
 suggestions were given a fair but brief consideration and never brought up 
again. This is not because the Struts community is apathetic to the needs of
 its users �� nothing could be further from the truth. These people write so
ftware that they give to the world for free.
The most likely reason they didn't implement his change is because it would 
have required rewriting several core classes in their infrastructure and wou
ld probably have introduced unwanted complexity to the application. In addit
ion, it is questionable whether or not this particular feature would enjoy a
 broad enough use to warrant inclusion into the default feature platform for
 Struts. As a result, the novice developer and his company are forced to rew
rite portions of Struts to add crosscutting, system-wide behavior. There is 
no ability to plug in crosscutting system logic or to easily extend the feat
ure offering of the platform.
In this way, Struts has failed to pass Reenskaug's second, fourth, and fifth
 requirements, that "the total system must be capable of continuous growth, 
it must be possible to add new subsystems or change old ones without disturb
ing the total system. It must be possible to include 'foreign' systems devel
oped by other people without upsetting the total system." He stresses the po
int twice, and for good reason �� the only guarantee we have in technology a
nd business is that our needs will change. Systems that are incapable of cha
nging in a fluid manner will inevitably fail to meet our needs, and we will 
find ourselves facing the difficult challenge of migration to the next gener
ation.
Fragmented Development Community
Another unfortunate side effect the MVC antipattern has had on our community
 is the fragmentation and polarization of its members, who have in recent ye
ars become entrenched around dozens of incompatible technologies. Business l
eaders are forced to choose between a myriad of nonstandard options, whose f
eature offerings largely mimic each other.
Earlier this year, I began exploring WebWork as an alternative to Struts. Wh
ile Struts had been the first framework to separate the command URI from the
 underlying logical system (thus separating the concerns of the end user typ
ing in a URL from the developer chaining together actions in the servlet tie
r) and to introduce a rough workflow processor, WebWork was beginning to int
roduce the concept of interceptor chaining and a dynamic value store that us
ed an expression language for parsing through the contents.
But at the time, the WebWork advocates were focused on the differences betwe
en Rickard ?berg's implementation of MVC and the Struts implementation. The 
documentation has improved quite a bit since then, and the reader might get 
a sense that MVC is no longer the selling point it once was. At least a half
-dozen MVC derivatives have been introduced into the community, but none hav
e met with great applause. A good friend of mine swears he went to a present
ation by Craig McLanahan where he brought up a diagram of MVC and there were
 four boxes. Model, View, Control and ... ? There have been so many half-hea
rted explanations about how "actions are really Controller components and ..
" ad nauseum. I'm sure you've heard it all a hundred thousand times.
The point is that no matter how you cut it, spin it, twist it, melt it down,
 push, pull, or try to explain it, no matter how many books you write on the
 topic, nobody has ever been able to adequately explain how an n-tiered serv
let component infrastructure is supposed to implement the Model-View-Control
ler pattern.
And as a result of our insane quest after this philosopher's stone, we've ma
naged to splinter what could otherwise be an extremely large and potent sect
ion of the development community.
Rising, Ongoing Opportunity Costs
But worst of all, aside from the obvious conditions brought about by our stu
bborn adherence to this antipattern, we must also factor in the ongoing oppo
rtunity cost of our failure to build a common, extensible, flexible servlet 
component infrastructure that meets the continuously changing demands of the
 market and is positioned to take advantage of the technological progress th
at is happening all around us. In the meantime, the main competitors to J2EE
 are capitalizing on the unreasonable complexity involved with bridging the 
web-persistence gap.
Part Three: Refactoring the MVC Pattern
In this third and final part of the article, we retrace the footsteps used b
y Trygve Reenskaug to isolate the MVC design pattern and apply his modeling 
techniques to the servlet framework tier. We also introduce a new design pat
tern that specifically addresses the needs of servlet framework developers i
n the J2EE sphere.
Fortunately, we're not bound to the MVC pattern. If we're willing to do some
 legwork, the techniques developed by Dr. Reenskaug to arrive at an appropri
ate design for the problem of servlet framework architectures are at our dis
posal.
While we're designing this new pattern, we must keep in mind the five requir
ements listed above for a component framework. We know that we must create a
 system that can be decomposed into modular components, that the behavior of
 each subsystem component should be transparent to the larger system, that c
omponents should be able to plug in to the larger system, and that the syste
m should therefore be capable of continuous growth without adding complexity
 or management chokepoints to the development process. Finally, the inner wo
rkings of the system should be subject to some form of manual override, wher
ein a manager can redefine the system behavior at runtime without taking it 
offline.
Concerns of Architectural Components
We have to start by considering the different roles that different objects p
lay in our system. There are only a few higher patterns of behavior for all 
of the different architectural components in a servlet framework. If we are 
able to isolate those behaviors and capture them into interfaces, then our s
ystem will become more flexible and modular.
By considering the nature of the different components in a servlet framework
 and employing basic separation of concerns, we arrive at three different ro
les for objects �� three higher patterns of behavior that can be observed in
 all existing systems:
DataSource: In the most abstract sense of the term, this is a place from whi
ch data can be gathered and stored. It could be a message bean, a request ob
ject, or a map, and would have a set of very simple method signatures simila
r to a map.
Action: An action is the basic logical building block of a business system. 
Actions are all executed and needn't necessarily know the order of their exe
cution.
Workflow: The core concern of the servlet framework is to manage the executi
on of a sequence of Action objects using one or more DataSource objects. The
 internal logic of the framework that determines the flow of control over th
e request can be isolated in a Workflow interface.
And what about presentation components? First, bear in mind that the user in
terface for a system needn't necessarily be visible. It could be audible or 
thermal or even olfactory, so "View" components is an inappropriate and limi
ting term. Second, considering the requirements, it follows reasonably that 
our framework should easily plug into any type of presentation technology, s
everal of which are becoming extremely advanced and needn't be replicated.
Trying Out the New Design
How do we know this would work? Let's try applying this new design concept t
o a simple application like a card catalog, and if it doesn't work, out we'l
l refactor. The data written on the cards should probably be kept in some ki
nd of DataSource objects so it can be stored, retrieved, examined, and alter
ed. There are many different types of data object solutions. EJBs, POJOs, an
d XML are just a few �� the list goes on for miles.
Next, we'll want to operate on the data in the cards. Pulling them out of st
orage, putting them back in, shuffling them, erasing their contents, using t
hem as coasters, etc. This logic can be encapsulated in actions (preferably 
as fine-grained as we can get them). If we break down the actions into small
 enough pieces, we can use them in different combinations to get different e
ffects.
The decisions governing the order in which these action combinations are exe
cuted represents the application's workflow. To encapsulate this logic, we c
an write a series of workflow controllers whose job is to execute actions in
 a certain order. This workflow could be hard-coded into the program, but it
 would probably be better if we incorporated a dynamic, rules-based system l
ike Drools, so that the workflow logic could be controlled and altered at ru
ntime to meet the changing needs of the business.
Of course, all of the different, dynamic rules approaches require some kind 
of external data for directing traffic. Do we need to refactor the design an
d add another category for components? Not at all �� workflow descriptors an
d user input are just two more types of DataSources.
The actual human interface for the web application can take place in another
 tier, and its developers can use whatever solution they like for building t
heir components. They can share access to the same DataSource components, an
d can implement their own presentation components and tools for manipulating
 the data however they want. If they're smart, they'll probably use MVC or s
ome variant in their component design, because UI is where MVC shines.
Abstracting the Feature Platform
If we were able to break down system in this interface-heavy manner, we woul
d be able to abstract the actual features provided by the platform. Things l
ike form validation, value caching, dynamic EJB bridges, security integratio
n, and other actions could all be abstracted into a platform that actually r
ests on top of the underlying workflow system (or plugs into it �� I say pot
ato ...). At that point, developing feature platforms of useful and common a
ctions could be a cooperative community effort. Businesses could develop the
ir own libraries to implement application-specific, or even system-level, ac
tions without having to alter the underlying workflow system or even know ho
w it works, and development teams could combine their efforts to build libra
ries of mission-critical action components for common use.
The interface-heavy design could also potentially allow us to swap out entir
e portions of the workflow or action subsystems at runtime and replace them 
with custom, more specialized subsystems that are tailored to our individual
 needs. Imagine: exchangeable parts for servlet frameworks. With Maven, we c
ould dynamically assemble the framework and feature platforms at build time 
from specialized component subsets.
But it doesn't have to stop there. The social benefits of such a flexible, m
odular, and extensible system should be obvious. The different factions of t
he development community could reassemble around implementing commonly neede
d features instead of warring over architectural minutiae. Businesses could 
develop strategic, proprietary feature platforms that are fine-tuned to the 
needs of their companies, or could collaborate on common component libraries
 without having to get their changes accepted by the team developing the wor
kflow core.
And perhaps the best news of all is that the investments we've already made 
into the feature platforms of different frameworks could easily be ported to
 this new infrastructure. Features from Struts could be rewritten as action 
platforms and plugged into the framework without a hitch. It might even be p
ossible to write compatibility layers for existing action implementations, s
o that the end users don't suffer unnecessarily in making the transition for
ward.
Results and Conclusion
We all have this task in common: to implement a framework that will reduce t
he complexity of bridging the web interface to the application server, and t
o do it in such a way that it is flexible, extensible, and capable of consta
nt mutation throughout the coming years.
As open source middleware developers, we also share a common desire to impro
ve ourselves, our businesses, and our communities by collaborating to build 
better tools. The time is long overdue for each of us to reconsider our assu
mptions about the MVC pattern, to acknowledge the negative effect it has had
 on our community, and to work together to address the problem. We need to r
eevaluate our common technical and social needs, overcome our stubbornness, 
and completely abandon the MVC design as the cornerstone of the servlet fram
ework architecture. A new solution is waiting that addresses those needs.
In the next piece in this series, I'll back up my assertions with actual cod
e and introduce the Shocks Servlet Framework, a full implementation of the d
esign I've outlined here. I'll go over the architecture of the framework, di
scuss how it evolved conceptually, and show how it addresses each of the fiv
e challenges for frameworks Dr. Reenskaug laid out over thirty years ago.
N. Alex Rupp studied language and writing at the University of Minnesota.
View all java.net Articles.
? Post a Comment
Showing messages 1 through 14 of 14.
----------------------------------------------------------------------------
----
Titles Only  Main Topics  Oldest First
Excellent piece of work!
2003-12-17 11:59:23 nicolasdijkstra [Reply]
I have to say i totally agree with your point of view about MVC.
I've always had the feeling that there was something missing whenever i desg
ined a web application, tied to that antipattern.
I'm looking forward to reading your next and see an implementation of the de
sign you've outlined in the article.
Faulty logic
2003-12-15 09:56:59 ljnelson [Reply]
First off, I hate Struts the more I work with it. I think it is a terrible, 
overgrown framework.
Having said that, I think N.'s argument comes down to something like this:
1. Struts is a servlet application.
2. MVC was applied during the development of Struts.
3. Struts is unwieldy.
4. Therefore, when you apply MVC to a servlet application, you get unwieldy 
architectures.
An equivalent argument runs like this:
1. It is currently raining.
2. It is currently cloudy.
3. Therefore, whenever it is cloudy, it is raining.
More at http://www.jroller.com/page/ljn.
Cheers,
Laird
Faulty logic
2003-12-16 09:49:07 n_alex [Reply]
> First off, I hate Struts the more I work with it. I think it is a horrible
, overgrown framework
Tell us how you really feel, Laird.
Laird, I'm concerned that your personal feelings might have interfered with 
your *own* logic in this regard. It has apparently interfered with your boil
ed-down presentation of my research. I urge the other readers not to take ha
teful rants like these too seriously--they're usually more self-indulgent th
an constructive and productive. And ultimately, code always speaks louder th
an words.
I've posted a logical summary of my argument at the Shocks site to address p
osts like this. Hopefully it can show with a little humor what I'm trying to
 express here.
It's a very difficult topic to write about, and the temptation is always to 
let it devolve into emotional and illogical rants like Laird's. I'm only try
ing to introduce some ideas to an evolving and unresolved problem space. I h
ad fun writing Shocks and I'm having fun using it, but I don't expect anyone
 else to do the same. I'm more concerned about reexploring these old ideas. 
So if the ideas from this writing are revived and other people begin integra
ting these ideas (which are, I remind you, not my own) into their own work, 
I'll be very satisfied.
I've gotten such great feedback and am learning so much about this problem s
pace that I'm happy no matter the success of my software project.
Best,
--
N. Alex Rupp
Based on an invalid premise
2003-12-15 07:12:36 sage_sam [Reply]
So far, I have yet to hear a valid point on the failure of MVC to meet the r
equirements of the MVC framework.
The author picked one particular post on a highly active mailing list (the S
truts User list) as an example. Even assuming, despite the immense traffic o
n the list and ongoing development of struts, that he picked a valid target 
for his criticisms his points and discussion are invalid.
The author wishes us to believe that, because of one item, "Struts has faile
d to pass Reenskaug's second, fourth, and fifth requirementsthat 'the total 
system must be capable of continuous growth, it must be possible to add new 
subsystems or change old ones without disturbing the total system.'"
Just to review, the points in question are as follow:
2) Divisible into modular subsystems.
4) Subsystem modules are pluggable.
5) The total system is capable of continuous growth.
It must be considered that the item that he points to has nothing to do with
 item #2. The discussion that the author points to is about a particular imp
lementation of core logic.
However, even if I concede that maybe it does touch on the issue of modules,
 there is a larger item he fails to consider:
Struts provides the very capabilty the author challenges. Search the Struts 
list and user documentation for 'modules' and you will find numerous hits--a
nd not just because something in the logic is called a module.
Struts' modules implementation does exactly what the author wishes us to vie
w as a failure. By simply pointing to a new struts-config.xml file in the de
ployment descriptor and providing subcontext, we can create a new module. No
 other modules care about it unless thye want to. It does not affect the oth
er modules. Thus, modules can be added or removed per needed business requir
ements. In this way, I would say that requirements 2, 4, and 5 are completel
y met.
In regards to the specific item, it is possible to provide a new request pro
cessor via a plugin or specified request processor in a module's configurati
on file. Requirements such as that provided by the user pointed out by the a
uthor can be included or excluded on a module by module basis.
If these three items are all met, then struts meets all requirements that th
e author laid out. If this is true, his contention that Struts does not fulf
ill the MVC requirements or meet the need is not true. As such, while I find
 the article an interesting discussion of the history and nature of MVC, I m
ust find his conclusion based on an invalid premise and hence completely ill
ogical.
An MVC-Terrorist
2003-12-12 15:36:12  [Reply]
 Trackback: Marc, himself, his blogs, and you reading them.
Dropped in the box via e-mail: Beyond MVC: A New Look at the Servlet Infrast
ructure. Just some days after making public some of my own views... And I'm 
really sold before it even begins: ...my goal with these two articles... ��
Not Exactly Enlightening
2003-12-12 15:12:27 ocean [Reply]
I guess I stand alone but I thought the article was pretty silly.
The origins of MVC was kind of interesting but not exactly critical. And cla
iming that MVC is an antipattern because the developers of Struts decided no
t to include some feature... uh... Perhaps I'm missing something, but you ne
ver actually explained why MVC doesn't work in servlets.
Next, there are several well-known problems with the solution you propose. U
sing Maps as your model? It's been done several times and it always turns in
to a maitenance nightmare--either that or developers end up writing static a
ccessor methods like OrderUtils.getPrice(Map). Next, the Action/Workflow thi
ng is hardly new. And note that talking about Workflow doesn't actually solv
e the problem. You will still need to write some sort of complex request dis
patching logic which examines an incoming request and selects the best workf
low to execute. This is why so many MVC frameworks (like Struts...) fall dow
n.
I've said it before and I'll say it again: the problem with MVC frameworks i
s that they are frameworks. They impose way too many constraints on develope
rs or they inevitably work their way down into business code. Developers ine
vitably chafe under constraint X or they don't like API Y so they run off an
d invent their own framework. It's a vicious cycle really.
Now, I didn't invent MVC, but I've used it a great deal (particularly doing 
Swing development), and I believe the real value-add of MVC is it's ability 
to let you 'wire' together complex components. (Events are also very importa
nt.) This is what the goal of any servlet-side MVC 'framework' should do. It
 should basically just be glue that can be quickly smeared onto your real ob
ject-oriented API. IMO, just having an 'Action' interface is probably a bad 
idea. Nobody knows what actions are (are they business logic? Then maybe the
y shouldn't be tied to the Servlet API. Or are they just sophisticated contr
ollers that forward to 'real' business objects?) and I've never seen a busin
ess process where 'Action' was a first class concept. Note that in your own 
system, the card catalog, the Action concept isn't there. I see Cards, a Car
d Catalog, and possibly a transactional data source (though really that's an
 implementation detail) but I hardly see something you would call an 'Action
'.
I'll just conclude the rant by saying that sometimes if something is difficu
lt you just shouldn't do it. I see people tearing through different framewor
ks without ever once stopping to ask themselves why. Maybe the problem that 
shouldn't be solved. Personally, I wouldn't put too much money on any sort o
f 'servlet application framework'.
Not Exactly Enlightening
2003-12-13 06:49:52 ljnelson [Reply]
While I don't think the article was silly, I agree with you in many respects
 I'm glad N. wrote it however; it's an articulate look at the frustration t
hat drives us web developer types to romp off into the woods and do our own 
frameworks and middleware.
What's interesting about the whole HTTP/HTML paradigm is how it forces you t
o deal with events. Swing and other GUI frameworks are often written in term
s of reacting to events, but for some reason when we are confronted by web a
pplications we prefer to think in terms of workflow, or scripted actions. I 
wonder, honestly, why that is? That is, if we took the same web application 
and turned it into a desktop application, we would have no problem writing c
ode to react to button events, focus changes, etc. Can't these concepts be r
eused in a web setting?
Cheers,
Laird
Where the rubber meets the road
2003-12-12 11:54:48 skidancer [Reply]
This sounds very nice, but do you have a reference implementation ?
Excellent article.
Where the rubber meets the road
2003-12-16 07:53:48 jt2190 [Reply]
http://shocks.codehaus.org/
good start
2003-12-12 08:15:03 macinfinity [Reply]
I think the idea of orchestrating the workflow is a big improvement to what 
we have today. My only concern is that you have greatly improved the model l
ayer of MVC, but perhaps we need a similar triad of roles for the view? I th
ink to trivialize the view as just another datasource will lead to system de
signs that only focus on data and not system behavior. Maybe I'm wrong. I li
ke the direction you are taking with this.
Good job!
Nicely ambitious
2003-12-12 07:17:42 ljnelson [Reply]
Well-written article.
I find it helps to think of web applications less in terms of page flow, whi
ch will lead you into the workflow swamp, than in terms of applications whos
e UIs are trying to accomplish common desktop tasks using suboptimal widgets
.
For example, a typical login sequence on a web application could certainly b
e implemented in terms of a page- or workflow--e.g. remember where the user 
was trying to go, make him log in, possibly route him in a circular flow unt
il he gets his password right, then point him where he was trying to go in t
he first place--but this is much more clunky than thinking of it as a perfec
t spot for a dialog box, if the web could only do dialog boxes correclty (us
er tries to accomplish function X, but we need to pop up a dialog box to aut
henticate him before we allow function X to continue). Dialog boxes and othe
r components on desktop applications that appear over the main application s
trike me as places where MVC might be applicable--framed this way, our task 
would be to figure out how to implement these sorts of desktop UI metaphors 
on top of the limited capabilities of HTML.
Ignoring the bizarre fascination they have with Swing for a moment, I like t
he ideas behind the echo web framework.
Cheers,
Laird
Some thoughts so far
2003-12-12 04:04:40 prpatel [Reply]
Another Web Framework - Shocks
Unit tests are on the way
2003-12-12 07:38:50 n_alex [Reply]
I had dreams about Unit tests last night. Believe me--they're on the way. I 
focused all of my effort in the first couple of months of serious developmen
t on just achieving the bare bones functionality, so I could use the framewo
rk in developing a new JMX console for MX4J & Geronimo and get these article
s published. Now that the bare bones functionality is there, I'm agressively
 writing unit tests.
And I'm absolutely open to refactoring the design. I'm looking at PicoContai
ner, AspectWerkz and Drools at the moment.
great work
2003-12-11 10:30:24 joshy [Reply]
This was a very enjoyable read. I've seen some very good and very horrible M
VC systems, and I agree that they simply falldown when taken out of the cont
ext of user interfaces. I'm really looking forward to the next one in the se
ries
--

Life is life.
�� ��Դ:���Ұ��Ͽ�վ bbs.nankai.edu.cn��[FROM: 202.113.25.3] --
�� ת��:���Ұ��Ͽ�վ bbs.nankai.edu.cn��[FROM: 202.113.25.3]