Why I like the Reactor Framework
Posted by Joe Rinehart at 4:17 PM
5 comments - Categories:
Reactor
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.
Simon Horwith wrote on 07/13/06 5:45 PM
Care to elaborate on what alternatives to Reactor you evaluated, and what you did and did not like about each?