I'm quite happy designing (in C# or Java) DAO-like classes with methods corresponding to meaningful queries and transactions (the specific and often complex ope

I'm quite happy designing (in C# or Java) DAO-like classes with methods corresponding to meaningful queries and transactions (the specific and often complex operations needed by the application, never "save an object" or "find all"). I encapsulate all database access, including dealing with connections and transactions; I have a single point of authority regarding where data come from and how I call update operations; and all objects coming in or out of the DAO are free of database dependencies (no persistence nonsense). DAO/DTO designs, in my experience, tend to go bad when there's inappropriate repetition and complication: slightly different validation in different operations, validation in client code, multiple similar queries without consolidation, unwarranted different classes used in different cases, translation between back-end dumb containers of data and marginally different front-end dumb containers of data instead of thinking about a proper data structure, and so on.