A data access object (DAO) encapsulates database statements behind an application-layer abstraction. Controllers use DAOs while defining business logic, replacing feature-rich in-memory objects with stateless database access. section 1.4.1
Moving from in-memory objects to DAOs changes the application’s guarantees:
- Database operations can fail because of rejected inserts, server crashes, or network problems. section 1.4.1
- Concurrent access requires protection against duplicate records and inconsistent data. section 1.4.1
- One business action may require coordinated writes, such as inserting rows for both a Conversation and a Message. section 1.4.1
- Database-backed tests require isolation utilities and run more slowly than tests of in-memory objects. section 1.4.1
Starting a conversation
A controller can call a DAO to create a conversation, but the operation is no longer an inherently reliable in-memory method call: inserting the Conversation or Message row may fail, requiring explicit failure and consistency handling. section 1.4.1
Use the architecture diagram to trace controllers, DAOs, and the database in the stateless application setup. section 1.4.1

