Ah, but you make the mistake of assuming that automated SQL generation == ORM. That's not the case, at least for us. I touch a bit on the framework we use at

Ah, but you make the mistake of assuming that automated SQL generation == ORM. That's not the case, at least for us. I touch a bit on the framework we use at Expat here: http://www.expatsoftware.com/articles/2007/03/examplecode-productioncode.html http://www.expatsoftware.com/articles/2007/03/examplecode-pr... Basically, you can think of it as an early-bound Rails. We use CodeSmith to generate a bunch of classes, stored procedures and unit tests based on the existing database schema whenever we make a change to it. Those classes, along with generated wrappers for all our hand-built stored procedures get compiled into the project. This saves us from ever having to guess what SQL we'll get for a given operation, and allows us to pause at any point and be looking at readable code that does real, undestandable work and that can be debugged through. That may seem like a minor distinction, but then I bet you've tried debugging thru ActiveRecord once or twice and I doubt it was any fun. This way, we keep the same fast development pace that a traditional ORM might give us, without sacrificing the debugability and maintainability side (or relying on Magic happening behind the scenes.)