An Architect's View

A lot of buzz and excitement surrounds Doug Hughes' Reactor ORM project (and rightly so) but it isn't the only game in town. As those of you who've seen my talk on OO and persistence (download the preso and code from the "software" pod on my blog, if you haven't), I talk about four ORM frameworks that appeared at roughly the same time: Arf!, objectBreeze, Reactor and Transfer. Arf! was intended to be a quick prototyping tool, inspired by ActiveRecord (from Ruby on Rails) but the other three were aimed at solving production scale problems. Reactor was the most ambitious and seems to have attracted all the attention. The other two got a bit lost in Reactor's shadow. I recently started taking a second look at the Transfer ORM library by Mark Mandel and it's really grown up a lot since I last looked at it. It takes a different approach to Reactor (and Arf!), not relying on the ActiveRecord idiom, but instead assuming intelligent business objects for which Transfer provides persistence. It may seem a subtle difference but it's an important one. A business object does not know how to create / read / update / delete itself - that's the job of Transfer itself - but Transfer provides the infrastructure to create and manage the business objects (as well as persist them). Transfer provides a solid event model (before / after observers for persistence operations) and has recently added full decorator support so you can write easily customizable business object CFCs that are "attached" to a persistable CFC that handles the core business object data. Transfer also provides very sophisticated caching machinery (which I haven't fully gotten into yet). Installation is clean and straightforward. Although Java code is used, no special attention needs to be paid to the JAR it needs because Transfer has its own class loader built in to take care of the JAR. Very slick! It also seems to be a very low overhead ORM, in terms of raw performance. Currently supports SQL Server, MySQL, Oracle and PostgreSQL but the approach it takes is much more generic than Reactor so adding additional databasess should be very easy. It doesn't use database introspection so there's less "magic" going on (which probably also contributes to the lower overhead in performance). Definitely worth another look. If you don't like the ActiveRecord style of persistence, Transfer might be just what you're looking for. Oh, and Mark Mandel created a #transfer IRC channel on DAL.net so if you have questions, pop in and he'll be there (during the Australian day time). I'll be there too.