Given the fuzziness of terms like "MVC"
and "Components", it's important that we define exactly what we mean say that
Barracuda provides an MVC Component model. This document is based on an email discussion
between Christian Cryder and Robert Leftwich about this very issue...
Hi Robert,
> I realised that the thing that threw me was the reference to the MVC
> definitions in the J2EE blueprints and the diagram reproduced from
> there in the Barracuda Event Model 30,000ft overview and that I was
> attempting to apply these broad, macro-level (in the sense of
> multi-tiered app design) definitions to the classes and documents of
> Barracuda, whereas in fact I should be using the more narrow,
> presentation level specific usage of MVC as used in Swing.
I think you're on to something very significant here; it's nice to see you making this
connection. As you have rightly observed, there are varying shades of meaning when
it comes to talking about MVC. Unfortunately, I think Sun's marketing machine has really
clouded the waters here; let me see if I can explain what I mean...
My introduction to MVC really came with Swing; I had heard of MVC before and even written
my own MVC gui implementation on top of AWT, but Swing was the first large scale example
of MVC where I went "Oh! Now _that's_ a good example of MVC!". Obviously, Swing
didn't invent or define MVC (and technically, Swing is really just a hybridized adapation
of MVC), but I think, however, that as far as implementations go, they really did a lot of
things right. The key (for me anyway) is that they applied MVC at a very granular level
(individual components), and then forced developers to use it by defining the concepts in
terms of interfaces.
That said, Swing only formally specifies the Model portion of the pattern in terms of
interfaces; the gui component itself comprises the view portion of the pattern, along with
some of the controller aspects. As the Swing team themselves notes: it's really more of an
M-VC adapation of the pattern, where the VC part is loosely defined and somewhat
intermixed. When you write a Swing app, you add additional controller logic when you use
event listeners to say "when this happens, do this [which may end up updating the
model]". So, Swing components themselves implement MVC at a rather low level; there's
nothing in the Swing framework that applies the MVC pattern to groups of components, or to
application flow.
(As an aside, I once saw a very good article on "Hierarchical MVC" that actually
recognized the scope limitations of Swing MVC and proposed a higher level framework to
apply the MVC pattern at the application level; it allowed for nested MVC triads and
addressed flow control issues. You can read more about this
concept here).
Ok, so Swing caught on and MVC became the talk of the town (and rightly so, imho). At any
rate, as the webapp paradigm emerged the folks promoting it looked to increase traction,
and one of the ways they gained it was by touting the MVC'ness of their approach. This was
described in early whitepapers as Model 1 vs. Model 2 (with the latter being the flavor
that stuck). The term Model 2 was usually explained by referring to MVC, and the two have
gradually come to be viewed synonomously by most people operating in the webapp paradigm.
The key point to note here is that Model 2 is MVC in a completely different sense that
Swing is. Model 2 is MVC focused at a much higher level; it's really more "MVCish"
than "MVC" because it focuses on high-level application flow rather than
low-level component interfaces. In other words, any web app can be Model 2; all it has to
do is implement the "control" logic separately from the "view" logic.
This is certainly a good practice to follow, but its also pretty nebulous.
(Another aside: there's actually a book called "AntiPatterns" which describes
the abuses of pattern theory; as certain patterns become popular people cite the pattern
in an attempt to add credence to their architectural approach and the terminology ends up
getting applied in so many different ways that the pattern itself becomes diluted and
ultimately meaningless. In many ways, the whole MVC buzz is an example of that type of
thing...just about every framework or approach out there claims MVC because the of the
perceptions associated with the terminology)
Alright, after all this we can clearly see how fuzzy the situation has become (heh heh!).
How does Barracuda fit into the equation? Well, from my perspective Barracuda tries to
address the high level flow control aspects of MVC (as per the "Model 2"
terminology) by using the event model. The event model allows you to process requests (via
control events)--you make business decisions and possibly update an underlying model
structure--and generate responses (via view events). This two phase processing corresponds
nicely to both HTTP Request-Response protocol and the Model 2 Controller-View pattern.
Barracuda goes a step further, however, and attempts to provide real low-level
component MVC (in the Swing sense of the word) via the component model. By this we mean
that most UI components have a corresponding "Model" interface, just like in
Swing. You put data in the component by putting data in the model. There are some
differences; Barracuda goes further than Swing in that it also defines "View"
interfaces (in addition to the Model interfaces). It is also intentionally simpler. But
it's still very low-level and is also strongly typed.
I think it's interesting to note that the whole term "components" is another
huge buzzword right now, which has really lost all sense of meaning. There are a number of
frameworks out there that claim to be focused on creating reusable components for server
side application. Unfortunately, the meaning of "component" oftentimes means
nothing more than just "a block of code" (so server side includes and taglibs
are called "component technology"; it's true, but only in a very loose sense of
the word).
To the best of my knowledge, there are very few frameworks out there trying to apply
component technology (in the Swing, widget sense of the word) to server side apps. On the
commercial side there's Hammock; there's also an open-source one called wingS over in
Europe (but it seems barely alive). I think both of these go too far, in the sense that
they try to build web apps in exactly the same manner as Swing apps, with the developer
designing everything. This works well in Swing, but not in the webapp paradigm (where
code/content separation is paramount). With Barracuda we're striving to strike the proper
balance; leverage the benefits of component technology (in the Swing sense of the word),
but do so in a way that is squarely aimed at the webapp paradigm (ie. is not just a
server-side port of Swing).
> When I looked at CompConfig.java and saw that getItem in the CompModel
> class was returning various components such as a BSelect, BAction or
> BToggleButton I thought hang on, why is the model part of an MVC
> framework dealing with these very specific UI components?
The answer to this question is that it actually mirrors the Swing implementation: if you
look at JList, JTable, etc you will see that the models can return other Swing components.
The controller logic embededded in the actual components is intelligent enough to examine
the _type_ of data coming back from the model and handle it appropriately. While it may
not be proper MVC in the purest sense of the term, it's how Swing works, and consequently,
how Barracuda works too.
The important part in all this is to be very clear about what we mean when we talk about
"Barracuda MVC Components". Hopefully this helps clarify. |