So, I'm typically not a lover of ORMs as they're typically implemented, and tend to also favor doing something close to the sproc-based method that Philip-J-Fry

So, I'm typically not a lover of ORMs as they're typically implemented, and tend to also favor doing something close to the sproc-based method that Philip-J-Fry proposes in another comment. It's always struck me as odd that, as a profession, we generally agree with, and can be quite fanatical about, the idea that different modules and services should try to hide their implementation details as much as possible, and instead speak over well-defined, constrained protocols such as APIs or interfaces; but as soon as an SQL database comes into the mix, we happily throw all that hard-earned discipline out the window and go back to directly swizzling the internal state of external collaborators. That said, there are some use cases where I'm not sure how you get around something like an ORM. One is when you need to allow users to execute arbitrary searches against the data. If that's your situation, then, any way you cut it, you're going to end up with some system that takes an abstract representation of a query and compiles it to SQL. The only question is if you want to use something off-the-shelf to do it, or if you'd rather hack it together yourself. In my experience, there are few things on this earth that present a greater maintenance burden than a homegrown ORM-type library does once the original author has moved on to other things. And there are others where avoiding an ORM is over-engineering. If your database is just an honest entity store, and you're just doing fairly straightforward CRUD operations against it, and it belongs to a single application, go ahead and punch the easy button and have a happy life.