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.

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.

During my lunch break, I flipped a few bits to make the new Model-Glue site live. It's a bit experimental - it's running on a bleeding edge of the Unity release and prototypes of a few Actionpacks like "Headstart" (for security) and "Messageboard" for, well, simple message boards.

I've posted another talking-to-fast-this-is-a-demonstration-not-a-tutorial video to YouTube. This time, it shows definition of one-to-many and many-to-many relationships, how they're handled intelligently by scaffolds, and a bit about dictionary files.

Sorry for the audio, I used my laptop for this, and it seems to skip a lot and eventually get out of sync. It's about all I can do while on the road, though.

I am looking into a copy of Captivate to provide proper video tutorials once Model-Glue:Unity is released.

Well, my CFUnited travel started early yesterday afternoon. I'm up in Northern Virginia to visit my in-laws and some old friends over the weekend, then to do a few speaking engagements on Monday and Tuesday. I'm going to have a bit of lag time tomorrow afternoon, so I may record a new Model-Glue video showing some more advanced scaffolding...

Well, my CFUnited travel started early yesterday afternoon. I'm up in Northern Virginia to visit my in-laws and some old friends over the weekend, then to do a few speaking engagements on Monday and Tuesday. I'm going to have a bit of lag time tomorrow afternoon, so I may record a new Model-Glue video showing some more advanced scaffolding...

After Sean Corfield clued me in to the performance impact of things like DuckTyping instead of strict typing in low-level code (like frameworks), I made some large changes to the Model-Glue:Unity core in terms of arguments and returntypes.

The result: whoa, that's fast.

Here's a few benchmarks from a 100-concurrent-user load test:

Application Template

Model-Glue 1.1 - 3095ms avg. request time

Model-Glue 1.1.1 RC1 - 1428

Model-Glue:Unity Beta 1 - 1430

Model-Glue:Unity BER - 596

Petmarket

Model-Glue 1.1.1 RC1 - 2892ms avg. request time

Model-Glue:Unity Beta 1 - 2602

Model-Glue:Unity BER - 2115

Lesson learned: ColdFusion checks metadata for typing and requirements at runtime. If you're in situation where every ms counts (like the Model-Glue request lifecycle), you may want to thing about loosely typing your code.

If you ever wondered what is the best parental control software on the market, I strongly suggest you visit the Kids` Shield website. Some of the solutions leverage our own frameworks and are simply brilliant.