Objects and Persistence (CFObjective Session Summary)

Sean Corfield gave this presentation which covered the ways in which objects can be persisted (with a friendly reminder that the application scope is not a persistent scope because it does not persist when the machine is turned off and back on). Sean emphasized that when moving to an object-oriented architecture for your applications, it can be confusing to try to determine a strategy for translating objects to a relational database (rdbms). On a personal note, I have to completely agree that this is what has (and continues sometimes) to cause me the most difficulty (see my previous post on this topic exactly).You use a Data Access Object (DAO) to save, load and delete object instance data to the rdbms, while a gateway would be used for bulk query operations. While this may be easy to understand (IMHO), the complicated part, which Sean covered, is that an object is not necessarily a single row in a database (i.e. a single record). Your object could span multiple tables or a single table could, in fact, store multiple object types. An additional item that can cause confusion is that a database requires some sort of primary key, but this is not a necessary part for your object instance; however, Sean still recommended simply storing the key data in your object instance as the simplest solution to this (he gave the example of Hal Helms using a default object id in his baseComponent that all objects extend). Another related point Sean made is that you shouldn't think that you have to map query rows returned by your gateway into arrays of objects; it is Sean's opinion that the ColdFusion query object is sufficient encapsulation.

Part of the solution to the complexity of handling the translation of objects to rdms is the use of frameworks such as Arf!, ObjectBreeze, Transfer and Reactor. All of these use the concept of active record, which, in very simple terms, are beans that know how to save and load themselves. Sean covered the four frameworks mentioned, and some of the differences between them.

Arf! relies on the undocumented ColdFusion service factory. Much like Ruby on Rails, it takes the "convention over configuration" approach and requires certain naming conventions for database tables and columns. Sean said that it is his understanding that there isn't any continued development planned for Arf! and that it isn't really intended for use within a production application.

ObjectBreeze (which just hit v1.0 and added Oracle and PostgreSQL support) differs from the others in that it provides a means for establishing relationships between objects at runtime (rather than a config file or convention). This means that it setup is quite simple and it also doesn't generate "skeleton" components (i.e. no hard-coded components are generated). Currently it does not include any sort of built-in validation.

Transfer, as Sean described it, is more about "smart business objects." In this respect, it assumes you are writing your own gateways. It has some unique features, like the ability to specify CFML to inject into your objects and before and after observers for DAO CRUD operations.

Reactor has full gateway and validation support and now has an event model. It does generate shell components which you can add custom code to. These shells are generated per supported database, which Reactor supports quite a few including MS SQL, MySQL, PostgreSQL and Oracle (I think DB2 support exists but is still being worked on). There is currently a lot of development going on in Reactor, which Sean is involved in, and new features continue to be added. Reactor has support for many types of relationships between objects. (note: for a more detailed walk-through of Reactor's features, you can read my Getting Started with Reactor post)

Sean pointed out that all of these frameworks currently assume a one-to-one relationship between an object and a table. This means that an instance of an object will equate to a single record in the database.

Prior summaries are available: Subversion, Positioning ColdFusion, Duck Typing and Using Factories and ColdSpring AOP.