My persistence Service layers are a combination of business database logic and relational object handling. As I've said elsewhere, anything higher up than this layer deals only with detached (POJO) objects, and is therefore not transactional in database terms. Business database logic is logic required to maintain persistent store integrity and abstraction and should not be confused with non-database business logic (such as, say, computing mortgage amortization tables).
The business methods deal with persistent objects in relation to each other (a "working set"). So you might retrieve a network where you have a customer, recent purchase orders, purchase order details, customer contact info, as a
unit. This set might be modified in whole or in part and persisted back as a single transaction.
The DAOs each deal with a single database table (entity type), or, occasionally a parent/child table set if they are bound closely enough. So there'd be a separate DAO for customer, one for customer contact info, one for purchase orders and maybe one for purchase line items.
As far as I'm concerned, NONE of the update should be considered as "real" until the service method returns. So the fact that the data has not been physically transferred to the database before that point is immaterial. All that's required is that I keep a consistent image of the particular working set instance within the current transaction. Whether that image is entirely within ORM objects or helped by meta-data is of no special consequence.
It works well for me. I've done it this way on multiple projects and it's much easier to understand and maintain than what I'd been doing before.