This is a response to Jeffry Houser’s critique of Model-Glue. You should read Jeffry’s post before this one, as I directly respond to some of his points. To cut to the chase – me too, Jeffry, me too!
I’ve used M-G for two medium size projects. Like Jeffry, I can’t see a case where I’d use it again.
I couldn’t agree more about the event/view structure – this is just a global scope by another name, which as a way of passing variables takes us back about 40 years in programming language evolution. Yes, there are intelligent ways to use it, but the fact is that a robust mechanism for defining APIs already exists in the language (public function parameter lists) and a really great argument needs to be mounted for disregarding it. So does the rest of M-G mount that argument?
It seems to me that the heart of M-G is the implicit invocation mechanism. Essentially this is an event-driven programming model, and like all event-driven programming it supports very strong decoupling. At the point where you raise an event, you have no control [but see Brian’s comment below] over who will handle the event or what they will do with it. This is a powerful technique with applicability where system behaviour needs to remain loosely specified until load-time or even run-time (this is why you can change the menu structure in Microsoft Word while it is running). The tradeoff is increased opacity, increased debugging difficulty, and greater emphasis on good design – or to put it conversely, it’s much easier to make a mess of it.
As a programming model, it absolutely is not what I want when I’m setting up an average web app. 99% of the time I know exactly what controller function I want to invoke, I know exactly what data I need, and stating that with clarity is good design. Adding several layers of indirection adds no value at all – rather it greatly increases the risk of regression during future changes. As mentioned above, M-G tends to obscure the APIs of the various components rather than help define them. This is not to say everything should be hardwired. My beef with M-G is that it pervades the whole application, unlike techniques such as dependency injection and aspect-oriented programming, which let me introduce extra abstraction and complexity only where I get the payoff.
As a piece of software, M-G is a great achievement. It’s just the wrong tool for pretty much every job I have. The tragic thing is that, even if I did have to write a complex event-driven GUI, I’m pretty sure I wouldn’t be using ColdFusion to do it.
A minor disagreement – I don’t think there’s anything wrong with the view having a dependency on the model. In fact it’s kind of absurd to think that a view can avoid having a dependency on the data it is representing. The important thing is that the model doesn’t have a dependency on the view. (Trygve Reenskaug’s original MVC pattern is instructive in this regard, although it’s not directly applicable to the web). So having to pipe all data via the controller is another layer of useless indirection. Having said that, there’s a fair bit of confusion about where the boundaries between the controller and the view are, so maybe this is just an issue of definition.