Well, Wayne asked me to drop in with another viewpoint just to try to get as many as possible.

ORM = Incredibly annoying to inherit. ORM is (personal experience opinion) the shortcut devs take to proper database designing and coding... and I'm all for it for an application that can fit into MS Access instead, or never really needed a DB Dev in the first place and you just needed a datastore and had MS SQL handy. CRUD procs are quick and easy to generate and the ORM has little reason to need to do that. Anything else is usually a major performance fail.

Inherit a project that's been in ORM for a year and you inherit a disaster area. Especially if you're not given time and resources to cleanup the mess. Yes, I tend to consult at a lot of shops that never had a strong jack of all trades on staff.

However, I'll defer to the comments above that it *can* be done right. I don't know ORM very well (and I probably should, there's just so much time in a day). I just know the utter crap I've inherited that they've built and either have to live with or workaround. It's like anything else, where do you want to spend the time? In the beginning, or at the end? Either way, you're going to be spending time designing properly.

Oh, yeah, one other thing I've heard: It's great for 'prototyping'. Have you ever seen a prototype get a complete re-architecture between the prototype and the beginning development stage, or do you always "work with what you've got so far"?

I've never seen ORM work well. At best, it's semi-invisible on apps I never have to care about the optimization on. At worst I've made CIO's cry when I tell them it's time to rip out ORM and start doing it the right way, because they're too entrenched in the model and everything's too tightly coupled. Your webscreen should not dictate my table design.