Recently there have been some questions as to whether to close down the CF Hibernate Yahoo group as there hasn't been much traffic. But it seems to me like there is still a reasonable amount of latent interest in Hibernate in CF and from what I understand it should be easier in CF8.

I know Joe posted on this recently, but is anyone using Hibernate for real as the persistence mechanism for CF apps? I know Kurt has also talked about persisting VO's from CF to Hibernate, but has anyone got a real world app working end to end?

If so, are you using Kurts code for persisting the CFC VO’s? How do you handle lazy loading in CF using Hibernate? Are there any event notifications in Hibernate and how hard is it to “handle” them in ColdFusion? How do you handle the errors returned by Hibernate? Anyone got any sample code to share beyond the single listing by Joe and the one by Kurt? Any performance issues? And issues logging/debugging Hibernate issues?

Comment below or join the Yahoo group and let us know what you've been doing!

It is interesting to see the change in tenor on the mailing lists recently when discussions turn to DAOs, Gateways, Service classes and the like. I won't say the Gateway is dead, but when I say it's feeling unwell, I'm thinking of Soviet era Russian premiers as I think about it . . . :->

[More]

The ideal ORM is dependent on your exact use case. From Transfer and Reactor to SQL Alchemy and Hibernate, there are many ORM systems available of varying complexity. Here's what I need from my ORM system. I'd appreciate any input on features I haven't mentioned along with a sense of the problem they solve. This spec works for me today, but I'm sure there are plenty of new use cases just lurking out of site that I haven't thought through yet :-> . . .

[More]

I know there are lots of reasons to use a nested set model for storing tree-like data (pages, categories, anything where a record has a parent record), but I still like working with adjacency models as I'm still more comfortable with the ID and ParentID driving the tree rather than left and right numbers (although it may be because I haven't played with nested sets enough).

Anyhow, anyone who has ever tried to access data using parent IDs will admit, it is a pain, so historically I've just added metadata to the table to permit quicker and easier querying (yeah - I could have added nested set metadata, and may yet next time around). For now, I add an indented title (so I can easily display "- - SubsubPage" indented), a nest level, a global display order (an int which can be ordered by to return the tree in the correct order) and a file path (a concatenation of all parent names "/" delimited - useful for filtering recordsets and for easily displaying cookie crumbs).

I just put together a ColdFusion routine that (when called - after an insert, update or delete) re-creates the metadata for a given table. It works on any generic table with some kind of ID field, name field and title field (they can be called anything). OBVIOUSLY CF is not the place you want to run this as it runs one update per record. It works surprisingly well for a couple of hundred records, but I'm looking for someone to turn this into a MSSQL stored procedure (if anyone is interested, drop me a line :->).

Code after the break . ..

[More]

One of the challenges with many applications is that their databases and applications are tightly coupled. In fact, one of the arguments leveled at Ruby on Rails most often (other than the fact that the scaffolding isn’t very good!) is that it makes your business model way too dependent on your database tables.

There is no question that in simple applications, there may be a pretty good correlation between objects and tables, but once you get beyond trivial applications, you find a bunch of cases where your object model and your data model diverge as one is designed to optimize the comprehensibility and maintainability of your code and the other is designed (within reason) to optimize the performance of the persistence mechanism for the attributes of the objects that should be persisted.

I’d been thinking about this a lot. I distinguished attributes from properties and looked at issues like ordering by attributes. An interesting pattern I came across while perusing through Fowlers P of EAA was the Data Mapper which describes a pattern I have been working on within my DAO that allows you to have truly object based DAOs that use ORM patterns to handle the object-relational impedance mismatch.

To me, the goal of a DAO is to handle persistence, but ONLY the DAO should know about persistence specific issues. I don’t think the application should know that you persist date of birth rather than age. It should just be able to ask for a User object with an Age and the DAO should be smart enough to figure out that for Age to be displayed, date of birth needs to be retrieved and loaded into the IBO. That is what the data mapper pattern is for, handling such translations so that the object model and the database can be less tightly coupled.

There is an argument for putting the data mapper between the business object (or service layer) and the DAO. The benefit is that it would make the DAO simpler so if you needed to support multiple persistence mechanisms, all of the mapping logic would be broken out in a separate class that would then use an abstract factory approach to get the right DAO (actually the right DAO would be injected into the mapper using a programmatic config file in LightWire or multiple config files for ColdSpring). I haven’t decided whether to do this as the data mapper pattern isn’t very well known in the CF world and I don’t want to confuse people, so I’ll start with discrete methods within the DAO and then introduce a mapper if it seems appropriate when I’m working with the code.

I believe that on the whole it should be a general case best practice to wrap all recordsets within some kind of Iterating Business Object. It ensures that if you ever need to add calculated attributes (getAge() when the db only has Date of Birth), it won’t break your application and using generic getters and setters it isn’t that much additional work.

If the main distinction between a DAO and a Gateway is that a DAO returns an object then with this approach there is no real need for a gateway.

[More]