Data Access Objects (DAOs) are a common pattern for persisting Domain objects into the database. It's easy to confuse the DAO pattern with a Repository. The significant difference is that Repositories represent collections, while DAOs are closer to the database and are often far more table-centric. Typically, a DAO would contain CRUD methods for a particular Domain object. Let's see how a common interface for a DAO might look:

interface UserDAO 
{ 
    /** 
     * @param string $username 
     * @return User 
     */ 
    public function get($username);

    public function create(User $user);

    public function update(User $user);

    /**
     * @param string $username
     */
    public function delete($username);
}

A DAO interface could have multiple implementations, which could range from using ORM constructions to using plain SQL queries. The main problem with DAOs is that their responsibilities are not clearly defined. DAOs are usually perceived as gateways to the database, so it's relatively easy to greatly decrease cohesion with many specific methods in order to query the database:

interface BloatUserDAO 
{ 
    public function get($username);

    public function create(User $user);

    public function update(User $user);

    public function delete($username);

    public function getUserByLastName($lastName);

    public function getUserByEmail($email);

    public function updateEmailAddress($username, $email);

    public function updateLastName($username, $lastName);
}

As you can see, the more we add new methods to implement, the harder it becomes to unit test the DAO, and it becomes increasingly coupled to the User object. This problem will grow over time, with many other contributors collaborating in making the Big Ball of Mud even bigger.