Hibernate for CF (and a new TransactionAdvice)

Since I added Hibernate support to CF Groovy, I've been using that for pretty much all new development.  Oh, how nice it is.  The perm-gen issue is still lingering, but if after a few projects, I've realized that you don't actually end up touching your persistent entities that much, so it's not as big a deal as it seemed it would be.  Most of the work on those is done up front, laying out properties, relationships, and various helper methods and psuedo-properties.

Yes, my apps suffer from what Fowler has dubbed an "anemic business model", but I don't have great issue with that.  It's a concious design decision, not an anti-pattern that has cropped up without my knowing.  It's specifically driven by the non-CFML nature of the persistent entities, and as such they're not really full-fledged business objects.  Instead, they're more just value objects (or data transfer objects) both inside the app and between the app and the database.  I'm also a big fan of simple, and while I'm definitely not following the all powerful "best practices", I tend to weight simple as a higher priority than a lot of people.

I've also seen a signficant shift of Groovy code from the service layer up to the web layer, which is something I wasn't expecting.  My initial thoughts were that the web layer would stay almost entirely CFML, and the Groovy would be used for the backend code and interfacing with Hibernate.  The views are still all CFML, but my controllers are growing Groovy snippets all over the place, while the service layer is mostly just interfacing with CFML APIs from the Hibernate plugin, actually using Groovy for very little.

One little piece that I have't posted yet is a "port" of my TransactionAdvice CFC for use with the Hibernate functionality of CF Groovy.  The logic is exactly the same as the original, just no ability to set an isolation, and it requires a reference to the Hibernate plugin instance.  Download here: HibernateTransactionAdvice_b4173.zip.

8 responses to “Hibernate for CF (and a new TransactionAdvice)”

  1. Sean Corfield

    I'm curious: given that Groovy is slowly infecting the upper layers of your applications, why not write richer business objects in Groovy, i.e., instead of adding Groovy logic in the service and controller tiers, why not push that down into the business objects themselves?

    Like you, I'm liking Groovy more and more (and I'm only halfway through the Groovy Recipes book!).

  2. Mark Mandel

    This is something I have been pondering for a while, as I've been toying with the idea of enabling Transfer to generate Java and/or Groovy objects.

    What would be very handy is some transparent means to enable you to write your services in CFCs, but keep your business objects in Java/Groovy, and still be able to inject those CF CFCs into your Groovy/Java business objects, (Hopefully) in a very seamless manner, through the use of CFCProxy.

    I haven't worked out all the details, but that way you could keep the RAD nature of CF, but still be able to push it into your Business Objects (much like I do now in CF)

  3. Mark Mandel

    Yeah.. the way to have some sort of generated dynamic proxy would be ideal (that was the thought I was having), rather than having to invoke CFCProxy directly.

    There are performance implications, but I guess you have to pay a price somewhere if you want to hook CF into it.

  4. marc esher

    Do you work alone, or with a very small team? I ask because one of the implications I'd see here is a divergence among team members and their ability to maintain these applications. Without a strongly led effort to having the appropriate people learn groovy, I can see how you'd quickly get stuck in a situation where you're the only one who can maintain the apps. And that's no fun. In addition, politically, what happens when you introduce this and you hit a lot of resistance from other team members who simply have no interest/need at all to learn this new language? On top of that, there's the director/VP level to deal with. So you're selling up and selling down.

    On smaller teams with really agile people and leadership, this sounds great. In larger IT departments with the whole gamut of skills… yikes.

    Again, I'm asking only because I'm curious if you're yet in a position where you're trying to introduce this and I'm wondering how you're doing so, or if this is just a one-man-show at this point.



  5. Sean Corfield

    My team are mostly CFers from the ground up with some folks having more Java experience than others and some folks having more Flex experience than others. So far, everyone is liking their exposure to Groovy and building the entire backend for some AIR applications in Groovy and Java, leveraging Spring and Hibernate, is proving to be a fun and interesting experiment that will guide our technical decisions moving forward.