Ah, geez. It's been a few months since CFUnited, and everyone seems to be forgetting that us ColdFusion folks are people who get along really well when we're in person (and the bar hasn't run dry). Suddenly, frameworks suck, Model-Glue:Unity is a bloated kitchen-sink framework, and Mach-II is obtuse and maybe it "should be allowed to die a dignified death."

I guess that one of the responsibilities that I've gotten from Model-Glue is to speak up about it as well as frameworks in general when something is said that I feel is wrong.

Mom, please excuse the occaisional profanity. It's been a long day, I'm across the country from Dale and the dog, and I have to fly through O'Hare tomorrow.

So, here's my no-crap $0.02:

Framework's dont suck...

..and for some, they're not a half-bad way to learn things. For others, it's probably not a good idea. I've had some people tell them Model-Glue helped OO "click" because it got them thinking in terms of loose coupling and interfaces. It's also befuddled the hell out of some others.

Do what suits you, but recognize that others may not learn in the same way. Don't evangelize the way you learned as the way everyone else should, and recognize that others may learn in ways that you can't.

I'm one of the kids who couldn't learn to swim until I just jumped into the deep end. Some would drown. I probably never would've gotten over my fear of water, though, if I didn't just jump.

Mach-II isn't a dead duck...

...it's just different from Model-Glue (in MVC comparison). I've moved apps back and forth between the two for fun.

To be frank, if you're used to how J2EE does things, you'll probably like Mach-II more. If you're from ColdFusion or Flash, Model-Glue will probably make more sense. Either way, the differences aren't all that huge.

MVC Framework: not big deal.

Business model it connects to: big deal.

Model-Glue:Unity and "Kitchen Sinks"

Calling Model-Glue:Unity a kitchen sink framework or comparing it to an electric lawnmower with silly attachments is, well, just as silly as an electric lawnmower with a set of silly non-lawn-mowing attachments that doesn't have a beer holder. I mean, come on, if we're going to make crazy metaphors Dr. Phil would be be proud of, don't forget the beer holder.

Seriosuly, though, when Peter's post implied that I'm not giving enough considering to what goes "in" the framework, I took a bit of offense. I doubt it was intentional, and the picture in the CFUnited Flickr pool of us choking each other is a joke.

I've consistently turned down requests to add many features that would be useful to a subset of developers in solving edge-cases more elegantly but not to the Model-Glue community at large. I've had people get stinking mad at me over it, but it's something I've had to repeatedly stand up for. It's not easy to tell people that some code they've written is great for solving their problem but that it just doesn't belong in the framework. I've chosen to have friends get stinking mad at me rather than go against my judgement. It tweaks me that anyone thinks I've taken it likely.

The decision to provide scaffolding and ORM capabilities in Model-Glue:Unity was carefully considered. In the end, the pros simply outweighed the cons. I wrote and tossed three ways of doing it before I found a way that let me do three things:

1. Remove the tedium from creating basic data layers and master / detail lists
2. Make sure the generated data layer can be extended and refactored while allowing nondestructive regeneration.
3. Allow anyone who's used scaffolding/ORM to completely toss the Model-Glue based HTML interface without losing any data or business logic

Model-Glue extension vs. Mach-II extension

Peter says that the direction Mach-II is going is "extension through architecture instead of providing everything but the kitchen sink."

It probably wasn't intentional, but this underestimates me as a software designer, and it expresses ignorance of Model-Glue:Unity. The framework does, in fact, provide "extension through architecture."

It's simply doing it better than Mach-II.

Mach-II extension uses a plug-in architecture, requiring developers to use its framework-specific plug-in API.

Model-Glue:Unity has a rewritten core, dependent on an Inversion of Control container implementing the ColdSpring BeanFactory interface as an architectural paradigm for extension.

In other words, Mach-II has a framework-specific extension architecture you've got to learn, while Model-Glue has an extension architecture (ColdSpring) that doesn't even know Model-Glue exists, is an already widely used tool in OO ColdFusion, and is re-usable to provide the extension's service outside of Model-Glue.

In a market where we're going to need to provide the same services to HTML, Flex, and other clients, which do you think is advantageous?

Model-Glue:Unity and ColdSpring Dependencies

The framework creates no ColdSpring dependencies within your application. To claim otherwise is a statement of ignorance concerning ColdSpring: anyone who actually knows ColdSpring knows that no ColdSpring application is, in fact, dependent on ColdSpring. It's a beautifully clever thing when grokked.

If you'd like to get down to brass tacks about the lack of dependency, you could implement your own IoC implementation, meet a few interface requirements, toss ColdSpring out the window, and still run Unity.

In the real world, though, the extent of the ColdSpring requirement is that its files must be on your hard drive. Your applications don't need to know it's even there. Hell, no one on your team but the one who downloads Model-Glue needs to know it exists.

Big dependency, that ColdSpring.

Model-Glue:Unity and Reactor Dependencies

You don't have to even to download Reactor run Unity. It's not needed at all.

If you'd like to do scaffolding and automagic database functions, yes, you'll probably need Reactor.

I say "probably" because all of the Model-Glue code that knows anything about Reactor is isolated into a few specific places, defined via interfaces, and it's "plugged in" via that whole "extension through architecture" bit. It took Sean all of a few hours to re-implement and plug in the two components necessary to get Transfer mostly working (I'm not sure he's gotten around to scaffolding/committing hasMany relationships, but it shouldn't be too rough).

Big dependency, that Reactor.

Your application and its dependency on Model-Glue:Unity

If you create an HTML-based ColdFusion application, and you use a MVC framework, are you now dependent on the framework for that application?

Of course not: the point of the MVC frameworks is that just the HTML-based "client" for the Model/application is dependent on the framework.

Unity doesn't change that at all. You could use scaffolding to create a Widget editor, delete everything but the Model directory, and then use the same data tier in Mach-II.

Create a service wrapping the functionality, expose it as remote, and you've got a Flex application.

Big dependency, that Model-Glue.