There are workarounds for the drawbacks presented above. Many developers end up creating code generators which are used to generate the database abstraction objects. These work by using database-specific queries to inspect the database and generate the needed objects. Many of these code generators work by running a separate executable application which is used to manually generate the objects when needed.
Reactor is a similar concept. Reactor is an “Inline Dynamic Database Abstraction" API. This means that rather than running a separate executable tool to generate your code you would simply access the Reactor API directly in your code. Based on Reactor’s configuration, Reactor will generate objects on an as-needed basis.
For example, if you wanted a Gateway object for your Address table you could simply ask Reactor to create one. Reactor will generate this gateway as needed. In fact, Reactor will only generate an object when the object does not already exist and your database or configuration has changed (unless you tell it otherwise). In other words, if you have already generated the Address gateway and your database has not changed, Reactor will simply instantiate and return the object.
Ignoring how Reactor is configured, what follows in an example of all the code involved in creating an Address gateway:
<cfset reactor = CreateObject("Component", "reactor.reactorFactory").init(expandPath("/config/reactor.xml"))
/>
<cfset AddressGateway = reactor.createGateway("Address") />
That’s all. You now have an Address Gateway which provides methods which return queries. These methods are documented further on in this document.