Jun 24 2008

Project "Hiberailooving," Part 1

Posted by Joe Rinehart at 9:18 AM
5 comments
- Categories: Hiberailooving

Project "Hiberailoovy," Part 1

"Hiberailooving" - Combining Spring, Hibernate, Groovy, and Railo

ColdFusion 9 looks to be building in some measure of Hibernate support. Unfortunately, I'm impatient: I want to play with new toys *now*. I'm also looking to develop a small system based on a redistributable WAR, meaning that I'm open to just about any JEE technology. I'm still a huge fan of using ColdFusion for Service, Control, and View portions of an application, but I've gotten to the point where I'm pretty agnostic when it comes to the Model itself.

I've decided that I'm going to use Hibernate for my persisting my Model, which means CFC's are pretty much out for the language of my domain objects.

While I'm opening the door to moving away from CFCs for my model, I may as well make myself as happy as possible. I'm not a huge fan of writing getters and setters and other repetitive tasks, ColdFusion has made me love dynamic languages, and Actionscript 3 has made me used to being terse. To keep myself happy here, I won't be using Java: instead, I'll be using Groovy.

To sort out using Hibernate and make services and dependencies easily definable but loosely coupled, I'll be using the ubiquitous Spring framework.

Last, I need to be able to distribute what I'll be building as a WAR without requiring users to purchase into a license. That means Adobe ColdFusion 8 can't form the service/control/view tiers, and leaves me with OpenBD or Railo. OpenBD would require me to open source my project, and this is for commercial purposes. Hello, Railo.

Next Steps

To get this all working will require a good-sized change in my development environment and process. I'll need to change what I've got in Eclipse, get used to using Spring to manage my dependencies, move off of JRun, configure and use Hibernate's from within both tests and my Web application, and produce unit tests in both Java (for the Model) and ColdFusion (for the Service tier).

This Blog Series

This series of blog entries is going to chronicle my setup and use of this development and deployment environment. I'll be writing as I learn, so I may make mistakes that get corrected in a later entry. I won't be building my "application" at first. Instead, I'm going to build a small application (not sure what yet) that's large enough in scope to handle some complex cases (relating entities, etc.) but small enough to allow me to focus on the platform instead of features.

Next Up....

In my next entry, I'll document starting to develop the model. I'll get Groovy and JUnit (or TestNG) set up in Eclipse and try to build out a test for a Groovy-based entity.

Comments

Brian LeGros

Brian LeGros wrote on 06/24/08 9:52 AM

You should consider using GORM (http://grails.org/GORM) if you're going to use Groovy as a Java substitute. It makes creating Hibernate mappings stupid simple and adds a programmatic aspect to the game. What really sick about it, is that if you want to reuse your Hibernate mapping files, you can w/o issue. Grails uses it as its persistence layer, but you can use it w/stand-alone Groovy or Java (http://www.grails.org/GORM+-+StandAlone+Gorm). Talk about making Hibernate stupid easy, especially for green-field DBs.
Nitai Aventaggiato

Nitai Aventaggiato wrote on 06/24/08 10:22 AM

OpenBD does NOT force you to open source your application. IF you bundle with OpenBD you are required to do so by GPL. Other then that you are free to code and sell you application as you see fit.
Joe Rinehart

Joe Rinehart wrote on 06/24/08 10:40 AM

@Brian,

Thanks for the tip. I've looked at GORM pretty extensively over the past few months. While I'm not a fan of the ActiveRecord pattern, I figured it was a compromise I could make for how darn easy it was to use GORM within Grails.

Unfortunately, when I went the standalone route, I hit big blockers.

On the "things I can live with" side, I had to use Grails conventions to determine where I put my Model.

On the "things I don't want to work around" side, the dynamically added methods (finders, persistence, pretty much everything that makes GORM cool) can't be accessed via CFML (at least Adobe ColdFusion) because they're not on the class at compile time (instead being part of the metaclass, called via invokeMethod() at runtime).

I did build a GrailsDomainClassProxy.cfc that used onMissingMethod() and the metaclass to invoke these, but that sorta defeated a lot of the point, not to mention taking me back to the somewhat slower world of CFCs.

So, no GORM for me. The thing I think I'll miss is the automagic collection management methods. save(), findBy(), etc. can all be wrapped into generic DAO pretty quickly.
Joe Rinehart

Joe Rinehart wrote on 06/24/08 10:42 AM

@Nitai,

Think you missed this:

> I need to be able to distribute what I'll be building as a WAR

...meaning I need to distribute the whole thing as a bundle.
Ryan McIlmoyl

Ryan McIlmoyl wrote on 06/24/08 2:46 PM

Joe,
I'm very interested to see how this progresses for you, I'll be checking into this series often!

Write your comment



(it will not be displayed)