I try to be the guy who interops between the reactionary DBAs and the happy-go-lucky developers--two parties that optimize for different ends. So most recently

I try to be the guy who interops between the reactionary DBAs and the happy-go-lucky developers--two parties that optimize for different ends. So most recently, we had an app that started off with direct table access via an ORM. Once the data access paths stabilized somewhat, I started replacing them with stored procedures. Those stored procedures gradually coalesced to form an API. The ORM-like functionality is still there, if need be, but the stored procedures now provide a contract, much like a service. In retrospect, I'm not sure the ORM was even that useful. Besides encouraging certain bad habits on the consumer side (eg, most instances of lazy loading), its one more level of indirection to grapple with. Why not drop down to the database and write your implementation there? It can be tested right there and then, and directly in terms of the data flow: input -> output.