> > The people who think that ORMs are a good idea have a code-centric view of > the world. >
Stored procs! Here's the black hole of the argument. To me it's a simple reductionist problem... Clean-shaven code-centric people write real-world apps. Beardy DBAs design databases. Coders need databases. Databases are unlikely to have a structure that suits coders. What can bridge the "impedance" gap? Something has to. It doesn't matter how much you like stored procs, you still have to get stuff in and out of them across the gap to the coder's classes. How do procs help? Are you proposing that more business logic be moved into procs? If so, that way lies madness, as you can't easily integrate proc code into source control, testing, versioning, builds, etc. I've seen whole apps written in T-SQL, and it's quite frightening. Coders need ORMs, heavy or light. I've only used 2 this century, but they simplify and reduce code by a staggering amount. The benefits far outweigh the deficits. I was just discussing this with a colleague and we have made a casual pact that in future apps we will try to meet more halfway across the "gap". He will write procs that aggregate and deep load joined data for complex queries, then my code on the ORM side will query what the proc assembles. We haven't worked out the details of this plan, but I think it lets each part do what they are best at. The procs will assemble and shred data out of tables and the code will work with business objects. *Greg*
