Hmm.. not sure if I side with that article. My library writes the SQL. It was designed to solve more dynamic problems than mapping to hard coded beans.. but anyway, I'm not saying I would swap it for ORM on a "normal" application. As we love to say around here "the right tool for the job".
On Jul 18, 2:08 am, Mwanji Ezana <[email protected]> wrote: > On Jul 17, 1:49 am, Christian Catchpole <[email protected]> > wrote: > > > I started work on a "persistence layer" which didn't even try to do > > ORM. It was simply a tool to take the grunt work out of writing joins > > and handing the result sets. > > This reminds me of a few anti-ORM blog posts I've been reading > recently. For > example:http://manniwood.wordpress.com/2009/07/02/sql-generation-is-a-templat... > and a few other posts on the same blog. > > Once you hit things like graph navigation, query batching, caching, > etc. ORM benefits become clearer, I think. > > I get the impression that current ORMs handle the 80% case pretty > well. > > Mwanji --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
