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.