Inspiring

Answered

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

Forum|Forum|15 years ago
December 22, 2010
2 replies
1264 views

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

Advanced techniques

This topic has been closed for replies.

Correct answer Adam Cameron.

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

ecobb

Inspiring

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

A

Adam Cameron.Correct answer

Inspiring

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

Inspiring

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.

A

Adam Cameron.

Inspiring

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

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded