I've gotta agree with the stored procedure/view solution, despite the fact that I despise it in practice (since it when I've seen it suggestied, it's to pull the power away from the developers and hands it to the DBA), but it does have genuine speed benefits and keeps all the SQL out of your code.

I have the (dis?)advantage that I'm both the developer and the DBA. And the few times that I've had a dedicated DBA that wasn't me, they were still willing to let me write all of the code. (I just had to go through them to make changes).

The main advantages to views and stored procedures (at least in Oracle), is that I can tune the SQL with hints on indexes to use (or not use) and force the method of joins (eg, a sort-merge is typically better for getting all records, but a correlated join may look faster to the user if I'm paginating it)

I specifically don't like like the various modules to remove my access to the SQL, as they haven't given me the level of control that I want for tuning. (yes, I know I'm picky, but in one project, it was the difference between 0.62 sec to generate a webpage, and 0.10 sec, partially due to optimizing the table joins and use of materialized views but also removing some ineffective indexes, pinning tables in memory and creating some multi-column indexes for the most queried fields).