Дизайн ООП: Как включить обработку DB в объекты приложения

Это - проблема проектирования, с которой я регулярно сталкиваюсь, и я хотел бы найти некоторое общее понимание о предмете. Код, предоставленный здесь, является просто примером.

В стадии проектирования легко решить необходимость в объекте:

User
==========
Unique ID
Login name
Password
Full name

И легко преобразовать его в объект базы данных:

CREATE TABLE user (
    user_id INT NOT NULL PRIMARY KEY,
    username VARCHAR(15) NOT NULL UNIQUE,
    password_hash CHAR(32) NOT NULL,
    full_name VARCHAR(50)
);

Мои сомнения запускаются на уровне PHP. Очевидное преобразование:

Однако, как я должен заполнить фактические значения?

Я могу сохранить агностика DB класса:

user_id = $user_id;
        $this->username = $username;
        $this->full_name = $full_name;
    }
}
?>

Но затем я должен выполнить запрос где-то в другом месте...

Я могу инкапсулировать его в конструкторе класса:

user_id = $user_id;
        $this->username = $res['username'];
        $this->full_name = $res['username'];
    }
}
?>

Это выглядит изящным, но это препятствует тому, чтобы я делал много материала с классом:

• Проверьте пользователя именем пользователя, и пароль ($user_id еще не известен),
• Распечатайте информацию о пользователе из сообщений форума (я не могу позволить себе 100 запросов, чтобы показать 100 пользователям),

Скорее всего, я должен определить несколько классов, но я не уверен в том, как организовать его. Один базовый класс и много дочерних классов? Независимые классы? Единый класс с определенными методами? Возможно, это - известный шаблон разработки, но мне преподавали процедурное программирование.

Я также ценил бы некоторые идеи о:

• Обработка набора пользователей
• При хранении информации на сессии, таким образом, DB не должен быть запрошен по каждому запросу страницы

==== ДЛЯ ЗАПИСЕЙ ====

Я отметил ответ Gordon, поскольку ответ для него обеспечивает интересное чтение. Безотносительно, стоит отметить, что я нашел очень иллюстративный фрагмент кода в одних из комментариев пользователей на странице Object Serialization руководства PHP, которое может быть получено в итоге следующим образом:

• Это использует один класс.
• Экземпляр представляет определенного пользователя.
• Конструктор питается пользовательскими деталями.
• Класс обеспечивает статические методы для функциональности, это требуется перед способностью иметь экземпляр, например, выборку пользователя от DB идентификатором или именем.
• Пользовательские экземпляры могут быть сериализированы как данные сессии.

Не будучи гуру ООП, я нашел, что это очень простой все же убирает и полезный. Тексты ООП имеют тенденцию сверхусложнить простые задачи, и моя ежедневная работа состоит главным образом в маленьких проектах.