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.