Database integration is a hallmark of ColdFusion applications. Indeed, the
There’s also a real downside to this type of database integration. After all, consider what would happen to your code if a table name changed, or if columns were refactored and split, or if whole schemas were updated. Scary, huh? The downside of how most of us integrate databases into our ColdFusion apps is that we tend to write database specific code even at the client level, the code generating output or working with form fields, for example. In addition, we inevitably must write DBMS specific SQL, and that DBMS specific code needs to be managed by our applications.
Before I go any further, I must point out that
ColdFusion’s ORM support requires extensive coverage, which is way beyond the scope of this post, but here are the basics. In ORM, you never write SQL statements, and never really consider tables of rows and columns, at least not when writing client code. Instead, developers using ORM work with objects. For example, a table containing books with columns named title and author and ISBN, would have a corresponding object with the same properties. When using ORM, instead of retrieving a row from a table, you’d retrieve a book object (which is automatically populated by the contents of the table row). To retrieve all rows you’d not use a SELECT * FROM Books, instead you’d use Entity functions to request an array of book objects, populated and ready to use. And then instead of referring to column names in your code, you’d use Get methods in the returned objects.
This is actually far less confusing than it sounds, so let’s look at an example. First the Application.cfc:
this.datasource is used to define the datasource to be used, and then this.ormenabled is set to TRUE to turn on ORM support.
Next we’ll need an object that represents the table to be used, and in ColdFusion objects are implemented as ColdFusion Components (if you are working with multiple tables you’d have multiple CFCs, one for each table). Here’s Books.cfc which maps to the Books table in the specified datasource:
Notice that there are no methods (functions) in this CFC, there are only
Oh, and it’s worth noting that the new ColdFusion IDE (the subject of a future post) comes with wizards to generate these table CFCs for you.
And finally, here’s how to retrieve the Books data. First we’ll retrieve all books (this is equivalent to a SELECT *, but instead of returning a query, an array of Books objects is returned):
Of course, sorting and filtering and more are all supported. For example, to retrieve books with an author id of 10 (equivalent to a SQL WHERE clause) you could use the following:
Notice that to access the Title property, a GetTitle() method is used. This is a getter, and it is automatically created by ColdFusion. There are also setters, used to set properties within an object. To save a new or updated object you’d simple do the following:
This would work for an insert or an update, just save the object and ColdFusion and Hibernate figure out whether to update an existing row or insert a new one.
And we’ve even made it easier to bridge between using ORM and working with queries (for example, to be able to use
There’s a lot more to ORM and ColdFusion’s Hibernate integration. And ColdFusion developers get access to all of Hibernate, be it support for relational tables, lazy loading, caching, query optimization (by tweaking HQL directly), controlling all ORM settings, and much more, too. The next ColdFusion gives you the power of Hibernate with the productivity that is uniquely ColdFusion.