Barracuda Component Model - Defining MVC
barracuda.gif (11456 bytes)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.

For all the latest information on Barracuda, please refer to http://barracudamvc.org
Questions, comments, feedback? Let us know...