DataMgr is Better than ColdFusion ORM

Interesting article here, but I think you are off on a few points:

"Hibernate (in particular) has opinions about table structure. If your table structure doesn't match how it things tables should be arranged, you have extra work to do."
Well sure. If you want to use firstname for a column instead of fstname, then you have to tell Hibernate what the 'real' column name is. But frankly, you would only do that to improve the code in general. Ie, if you think fstname is a bad name (we've all seen horrible table/column names) then defining the alias in HIbernate is a _good_ thing. It's worth the extra 'work' (2 seconds ;) to provide a cleaner, nicer column name. The fact that you can do this is a HUGE win for ORM imho.

"Development using an ORM is supposed to make you "stop thinking about the database". A fine thing except that most ColdFusion applications are all about the database."
Right, and that's a mistake that ORM can fix. Just because many CF apps have been 'all about the database' does not, and should not, mean it should _stay_ that way. Frankly I'd much rather be concerned with business logic than table names.

"The SQL doesn't execute immediately in Hibernate, instead executing at the end of a Hibernate "session" which almost matches a ColdFusion request. This means you have to start thinking about Hibernate sessions."
I agree with you here. This is something you have to be concerned about. Frankly it is the biggest issue I can see with going to ORM. However, I do think the benefits far outweigh the mild 'penalty' here of having to think about Hibernate sessions.

"Single Datasource"
Point taken - but I've rarely, if ever, used more than one DSN. And - you CAN use ORM if your site has 2-N DSNs, you just have to restrict the ORM usage ot one DSN. I believe in most cases where you have multiple DSNs, you still have one core DSN for most of your content, and other DSNs for auditing or security. So I'd just apply ORM to the main content DSN.

"If you are doing pure OO, then you should probably use an ORM."

I'm sorry, but OO has nothing to do with learning ORM. Just because you write a CFC to use ORM does not mean you are using OO. A person with no knowledge of OO at all can easily grasp the idea of: My component is a table, each property a column. Yes, you work with entities and methods, so you can consider this pretty light OO, but I don't think it is fair to say you must be using "pure" OO to use ORM. "Pure OO" means so many things to many different people, I don't think then this is a fair statement to make. You need not know nothing of design patterns or frameworks to write a simple CFC.

Ray,

Thanks for the feedback. I knew I was bound to miss on a few points. Always good to learn.

My statement about table structure had nothing to do with column names. It was really drawn directly from Ben Nadel's experience (I linked to his entry in that section).

As to thinking about the database, I definitely see your point but in CRUD apps it looks (to me) like the whole "you aren't supposed to think about the database" thing just makes life harder. I certainly don't think you think about table names any more with DataMgr than with ColdFusion ORM.

As to "If you are doing pure OO, then you should probably use an ORM.", you are definitely right. I really just meant that an ORM provides real advantage over a non-ORM DAL (like DataMgr) when you are doing "pure OO". Again, I agree that is a slippery concept and one I didn't want to tackle in this entry.

My point is that use of CFCs does not mean that you will get a savings out of ColdFusion ORM. Use of bona-fida objects, however, may.

NOTE: My comment is being flagged as spam. Going to try to make this go through. UGH. What the heck?? Grrr. Now I'm getting mad. I'm going to try to post one part at a time.

About your code block, to be fair, if you used 4 lines to set sData values, then 4 lines to call the methods, I'd skip the sData step completely.

Interesting post Steve.

Just for info, there is a error in your ORM code;

EntityLoad('Contact',sData.ContactID) will return an array of objects, in this case, an array with one element.

Ray,

First of all, sorry about the spam trouble. I messed up a regular expression. I think I have that fixed now.

I used "sData" to avoid choosing a scope. Since every scope in ColdFusion can be treated as a struct, I think of this as one of the major strengths of DataMgr.

Normally I would use a saveContact method and use something like this:

Application.DataMgr.updateRecord("Contacts",arguments)

If you are going to have a bunch of "set" methods anyway, then I would argue that you may be in a situation where an ORM is a good match.

Even so, if you save all of those to variables.instance (for example), then you could still use:

Application.DataMgr.updateRecord("Contacts",variables.instance)

That is no more work that ColdFusion ORM (except that you don't need an EntityLoad call).

Point taken about the ability to pass in a struct. Of course, once could build a generic "set" for your CFCs in CF9 ORM. ;)

@RAY

When you say that a person with no OO knowledge can use Hibernate with no no matter at all you are completely wrong.
I am not talking of easy application to show how to save a record but I am talking about complex app that will require a huge OO understanding in order to manage hibernate properly.
Hibernate is the most huge JAVA framewrok I have ever seen and took me years to know that in a good manner....do not make it to easy cause is not.

Andrea,

In fairness, I think Ray was just saying that you don't have to use "pure" OO in order to use ColdFusion ORM. Even so, I agree that ColdFusion ORM looks (based on several blog entries that I have read) to be more difficult to learn and use for real-world development that it at first appears.

Randy,

Thanks. I'm sure it won't surprise you to learn that it was you I was thinking of when I mentioned the single datasource restriction.

Hey Steve, thanks for the links! I somehow missed this entry when you posted it. :)

I was actually looking for your CF DAL/ORM comparison entry because I just pushed a version 1.1 Release Candidate of DataFaucet with the new persistence service feature, which means it's no longer a BER feature (like it says in that comparison chart).

From the looks of it, the persistence service in DF will be significantly simpler than the Hibernate integration in CF9. Honestly, I'm mildly surprised at how complicated the new Hibernate features look. The Hibernate sessions thing is the wierdest one imo and liable to cause the most confusion and problems in the long-run... at least of what I've seen. What happens if there's an error on the page? Does the Hibernate session still execute its changes or does it abandon them? I could see either choice causing headaches. DataFaucet has no "sessions" concept, it just updates the datasource as soon as it can. Which is immediately for relationships on previously saved objects, or as soon as the object is saved otherwise. The convenience of structure population is built-in to the save() method (much like the rest of DF), and multiple DSNs have been supported since the very beginning. ;)

Ike,

Thanks for the heads up on DataFaucet 1.1. I have been a bit busy and so I haven't kept up with the outside world very well.

I think many CF project do not need ORMs. For the many that do, however, I still think that they should investigate options such as DataFaucet and Transfer for just the reasons you mentioned.

Sorry about the spam filtering. I am planning to redo that in the near future. Contact form is fixed now - thanks for the heads up on that.

I did update the DAL Comparison page. Let me know if I missed anything and I will correct it.

Thanks Salvatore!

Gerald,

Thanks! I would guess some of ease you found was due to how well Brian architected Illudium, about which I have heard nothing but good things.

Good post filled of useful tips! I love how you have written it properly but purposely. I have learned a lot from you. Awesome job and more writings to come!