Model-Glue Bloating, Mach-II Dying, Frameworks Stinking...

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

Even more carefully planned was the architecture behind adding the capabilities, and it's important to understand that scaffolding and ORM were added in a way that introduces no dependencies unless you wish to use them. Which leads us to:

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.

13 comments - Posted by Joe Rinehart at 12:54 AM - Categories: Model-Glue | Reactor | Causing Trouble

Reactor vs. Other CF ORM/Database abstractors

In an earlier post today, I stated a bit of why I like Reactor, and why it's what I'm using for the automated database functions in the upcoming "Unity" release of Model-Glue. Simon Horwith asked a bit about which others I had looked into - here's the list, starting with my own experiments, "Arf!" and "Paste."

Arf!

Arf! was my own toy in which I created a "record factory" that would basically create a mixin that "blended" persistence and relational/composition functionality into any CFC extending a base ActiveRecord CFC. It had a bit of a Rails flavor to it, and I do have a production application running with it.

However, it causes a lot of "kitchen sink" CFCs that act as a service layer, gateway, and bean all surrounding a single entity. Great during quick prototyping, but a little bit painful when applications grow.

Paste

"Paste" never went public. It was intended to be a compliment to Model-Glue. Fueled by Inversion of Control, it was intended as a generic "inline" code generator that focused on JDBC metadata. You could define "types" of CFCs to generate via XML (like a "Gateway"), tell it where to put the "base" (like a Reactor "project" CFC) and customizable shell (like a Reactor /model/data CFC) CFC, and it'd spit out code based on whatever CFM-based template you wrote (I hadn't learned XSL yet, and stuck with what I know.)

Basically, you could plug in your own types of code to generate, and use statements like paste.create("gateway", "Contact") to generate whatever you defined a Contact gateway to be.

Heavy stuff, but a bit of the underlying architecture (generic code generation configured by Coldspring) is stuff I'm talking to Doug about for Reactor 2.0.

ObjectBreeze

I just have a really strong bias against getProperty(propname:string) and setProperty(propname:string, value:any) methods. To me, it's against the concept of programming to interfaces. However, I really like how easy this one is to use. It was a little like Arf!, but sort of different in that you just ask for an object instead of dealing with a hard CFC. I'm also not sure how you'd add additional business logic to a given entity.

Transfer

Transfer is, to say the least, looking very robust. It's just not quite as easy to use (for me) as Reactor. Basically, I saw Reactor, it clicked in my brain, and I've been able to use it very well while never actually reading the documentation. Haven't quite had the same luck with Transfer, but some of its capabilities (such as caching) look very promising. If it exposes table metadata, it'd be pretty interesting to try to build another ORMAdapter and ORMController implementation to see if I could scaffold and generic ORM using it instead of Reactor.

Woodi

I played with it for a bit, trying to use its libraries to generate basic persistence CFCs etc, but it didn't provide implementations of the patterns needed for MG:U, and was Oracle specific (I was doing an Oracle project at the time - it uses Arf!).

Conclusion

Reactor simply worked. Out of the box. It was simple, and it works the way I think (in respect to bean/dao/gateway CRUD). It allows me to simply add business logic where necessary, and doesn't try to build a service tier for me, which I rather like - I can refactor to one as necessary.

5 comments - Posted by Joe Rinehart at 9:05 PM - Categories: Reactor

Why I like the Reactor Framework

While putting together Model-Glue:Unity, I looked at a number of different tools people have written for abstracting databases to CF code. I was looking for something simple to use that was also powerful. Reactor fits this bill nicely, and I wanted to point out what sets it apart from a number of other tools: it's an "inline" tool that gives you a "birds eye" view of relationships.

Inline tool?

What this means is that you don't run code generation scripts or utilities. You just set up Reactor, ask it for something, and it hands you back what you've asked for.

I think this is a great advantage - when you do something like add or remove a database column, the change is simply reflected. There's no script to run or code changes to make (unless, of course, you delete a column something else needs!).

Birds-eye view?

I really like the concept of the Reactor.xml file. I've written my own little ORMs (see: Rocket, Paste, Arf!), and they all relied on the Rails-style hasMany() methods within each CFC and the like.

It was quick, it was dirty, and the moment I had more than 15-20 entities in an application, this became completely unmanageable! Reactor.xml's <objects> block functions much like a high-level diagram of your model in that you have a "birds-eye" view of the data relationships within your model. It feels very natural to me, much in the same way ModelGlue.xml lets me "see" my application's flow and relationships of pages to business functions from a high level.

5 comments - Posted by Joe Rinehart at 4:17 PM - Categories: Reactor