Very well said. Too bad you stayed anonymous so you can’t get the proper credit you deserve.

ORM is just a tool that can be used wisely and unwisely. I try to tell people that there’s no shame in just doing straight-up JDBC calls if all you’re doing is stored procedure calls or simple SQL statement. But lots of people can’t resist using the framework du jour just because it’s popular at the time.

It is not the gun that murders, but who wields it. It is not who wields the gun who commits murder, but who wields it unwisely.

– A grasshopper

Everything wants to be hyped, to get over the adoption factor. When wielded appropriately and under the right conditions, with the intelligent, knowledgeable practictioners, ORM (which I have done poorly) is of course with merit.

Hasty implementations, with unwise and illiterate implementation, is the result of poor understanding. ORM doesn’t cause this, just as AJAX doesn’t cause the web to “break”.

I’ll always remember the little league team that had all the studs on it, the kids who were natural athletes. They spent all their time practicing fancy throw-outs and pick-off moves. It was “expected” that they would always out-perform, so this expectation imposed an unreasonable work ethic.

The team that won the championship, though, was a team that worked, daily, on fundamentals. Throw, catch, run out the ball. Everyone bunts, everyone gets grounders, everyone carries the gear to the truck.

In the end, a good programmer knows the fundamentals of SQL as well as the fundamentals of programming. They’re paid for the results, not the fancy.

If a programmer can’t construct a SQL statement, and have not been doing that at least for a good while, chances are the results will not be as useful as that programmer thought.

Not the SQL fancy (triggers, stored procedures, data normalization, etc…) mind you, but the fundamentals: Create, insert, update, delete.

Programmers are paid to get it right, but the reality also says they’re paid to get it back right when it goes (sometimes spectacularly) wrong.

That always means fundamentals. Always.

If you are writing the same kind of error prone code over and over again (like having to check all try(s) have finally(s) for instance) is the biggest sign. Time to think of using something. Save your hands, check out like Groovy SQL first or an ORM.

Writing the same bland queries again and again? Are you really taking advantage of PL/SQL in a way an ORM couldn’t? If you answer yes and no, use the ORM, save your hands. They will thank you.

I actually think we probably agree more than we disagree. As I think I said in an earlier comment response, one of the largest-scale applications I’ve worked on handled tens of thousands of transactions per day for a wireless telecommunications client, and it was implemented using almost no ORM. Instead, we used a stored procedure framework to do the “mapping” (if you could even call it that) and it was *very* effective.

Your data dictionary approach is very similar to ORM frameworks I’ve used, even if it isn’t mapping first-order objects to entities persisted in a database, in that it has a level of indirection in the form of “mapping” client-side transient variables to columns in a table. It’s sort of an ORM without the O, and it’s actually pretty clever. In your particular example, I’m a little leery of the tight coupling between the View/UI, and the data Model (insofar as the HTML fields are directly coupled to your model map), but perhaps that hasn’t been a problem for you in practice because you still have one level of indirection there.

I think my biggest concern about the approach outlined in your blog was the advocacy of triggers – I’ve been bitten by trigger overuse and tend to use them as an enforcer-of-last-resort… I’ve gotten a lot of mileage out of distributing that work across multiple small servers before even hitting the database. YMMV. I’m sure it depends a lot on other factors like what RDBMS you’re using, how complex your data model is, etc.

Thanks again for commenting!

http://datastorm.sourceforge.net/motivation.html

@David – There’s lots to hate about ORM frameworks. It’s a tough nut to crack, and I’m not convinced that it’s been “solved” by any of the tools I’ve used. At one of my previous jobs, we created a framework which basically mapped Java POJOs to stored procedure parameters, and did all of the SQL in stored procedures. It actually worked quite well… I’ve contemplated building another framework like that for a side-project and open-sourcing it. I think iBATIS might also handle stored-procedure situations quite similarly (in the Java space), but I’ve never tried it.