To Hibernate or Not?? Using CF's ORM a good move?

[WestSide]

Hi,

I've always gotten by fine by writing stored procedure calls in my CF apps and have never really tried using an ORM to manage things and was wondering what others experiences are?  It seems like I would like some of the re-use of my stored procedures if I go with an ORM.  I could be wrong here so please let me know.  I'm interested to hear what folks think of CF9's ORM functionality.

Thanks,

-Westside

[Adam Cameron. · Accepted solution]

If you're comfortable with writing procs, then I'd stick with it.  I see the ORM approach as:

* good for people who aren't comfortable with SQL;

* only appropriate for small and simple applications in which generic SQL isn't gonna be too much of a performance hit;

* probably unnecessary convolution in those situations though.

Any high throughput database - ie for a large project - is going to want to have dedicated DB resources to create the DB tier, and that tier should be written on the DB, not in CF or in Java.  And each element should be specifically finetuned to be as expedient as possible.  Hibernate is not going to provide that: it's just going to create generic SQL statements, providing a "lowest common denominator" sort of solution.

I asked our DBA about Hibernate, and he just laughed, saying "you're not running that sh!t on my DB, mate".

I also think Hibernate is all about being expedient for the developer, not expedient for the solution, which is the wrong place to be looking for expedience.  Although perhaps in the CF world making things easier for the developer is the  name of the game...?

--

Adam

[Owainnorth]

I spent ages learning the ORM stuff when it came out in CF9, thinking it was going to be the absolute everything, and why would you ever go back to write your own queries.

That was about a year ago and I've used it once, to knock up an address book app for my parents. And even that was more a proof-of-concept.

Personally I know how to write SQL queries as well as I need to. I understand database tuning to a degree, and run every query I write through Oracle's AutoTrace to make sure I'm utilising indexes and joins as best as possible and to make sure I'm not pulling back any data I don't have to. I found it an alien concept not knowing what was going on at the database level so ended up logging SQL out to text files and examining it manually.

I personally found CF's ORM quite frustrating - certainly back then it was very much in its infancy and there were many times when you'd get back useless error messages (or sometimes, no error at all, just a blank CF error template) or even worse they would be misleading. As my databases tend to be fairly complex I quickly found myself requiring functionality not available through CF, which meant I'd then have to get CF to write the HBMXML files out and edit them manually, which was very annoying as CFCs and HBMXML files got out of sync.

It was extremely hyped up with CF9, but I think it's just too young a tool (in CF terms) to be useful at the moment. Also as Adam pointed out, the Hibernate engine is an absolute beast, and really is technological overkill for the majority of systems.

Unless you have a very simple system with pretty basic mappings, it's almost certainly quicker for yourself to develop a system in a way you understand, and you won't notice any performance difference.

[Adam Cameron.]

Unless you have a very simple system with pretty basic mappings, it's almost certainly quicker for yourself to develop a system in a way you understand, and you won't notice any performance difference.

You are dead right here.  However the question I ask is... for these basic systems in which CF's ORM stuff would actually fit well... I still question the point?  if it's a simple system... doesn't that make the SQL requirements simple as well?  So why not just code the SQL that add all the overhead of abstracting it out into Hibernate?

Possibly it fits if one is not comfortable with SQL, but I wonder whether getting one's brai around the vagaries of making CF's ORM stuff work isn't more complicated than learning the SQL?

I don't see it as a useful part of CF9 at all.

--

Adam

[Owainnorth]

I wonder whether getting one's brai around the vagaries of making CF's ORM stuff work isn't more complicated than learning the SQL?

Couldn't agree more, if someone starting out had the choice between learning ORM and SQL it'd be a pretty poor move to go for the former. Can't see myself using ORM again any time soon.

[WestSide]

Thanks for the replies.

I don't think I'm going to spend any time on it.  It sort of reminds me of cfinsert which I've never used, but from my knowledge <cfinsert /> was meant to hide the SQL or make it easy for folks to insert data into their database without knowing SQL.  I also thinking just being good in SQL is an invaluable skill that can be re-used across projects.

-Westside

[ecobb]

I'm always interested to see people's opinions on this, as I've wondered the same thing myself.  I posted this question on my blog not too long ago and got some good responses, (http://www.cfgears.com/index.cfm/2010/10/4/ORM-vs-SQL-in-ColdFusion-which-is-better)

I've always been a big fan of letting the database do the database work.  No third party system (CF, Hibernate, etc...) is going to be able to access a database more efficiently than the database itself can.  They may get close, but in the end I feel like letting the DB do its own thing with stored procs, views, etc..., will always win out.

That being said, I still want to use ORM on an upcoming project, if for no other reason than just to learn it so the next time I can make an informed decision on as whether or not to use it.  If I can cut my development time with negligible performance inpact, I may be all over it!

--

Thanks,
Eric Cobb
ECAR Technologies, LLC
http://www.ecartech.com
http://www.cfgears.com