Как эффективно написать классы объектов при работе с объединениями таблиц?

Question

Я должен начать с того, что я не сейчас, и у меня нет никаких заблуждений, что я когда-нибудь стану профессиональным программистом, так что большинство моих навыков были извлечены из опыта, в основном как хобби.

Я выучил PHP, поскольку он казался хорошим простым введением в некоторых областях и позволил мне разрабатывать простые веб-приложения.

Когда я узнал об объектах, классах и т. Д., Базовые примеры преподавателя охватывали идею о том, что, как правило, каждая таблица базы данных должна иметь свой собственный класс. Хотя это хорошо работает для проекта фотогалереи, который мы написали, так как у него были очень простые запросы MySQL, он работает не так хорошо, теперь мои проекты становятся все более сложными. Если мне требуются данные из двух отдельных таблиц, для которых требуется объединение таблиц, я вместо этого полностью игнорирую класс и обрабатываю его в каждом конкретном случае, ИЛИ, что еще хуже, объединяю некоторые данные в класс, а остальные как отдельная сущность и выполнение двух запросов, что мне кажется неэффективным.

Например, при просмотре контента на форуме, который я написал, если вы просматриваете ветку, я извлекаю данные из таблицы тем, таблицы сообщений и таблицы пользователей. Запросы из таблицы user и posts извлекаются через соединение, а не создаются в виде объекта, в то время как данные потока вызываются с использованием моего класса Threads.

Итак, как мне перейти от моего текущего положения к чему-то немного менее «глупому», из-за отсутствия лучшего слова. Прямо сейчас у меня есть класс БД, который имеет дело с подключением и экранированием значений и т. Д., Родительский класс запросов БД, который имеет дело с общими запросами и методами, и все другие классы (Thread, Upload, Session, Photo и те, которые не являются Используется почта, пользователь и т. д.) являются детьми этого.

Сделать ли класс больших сообщений, который имеет соответствующие дополнительные атрибуты, которые я получаю из таблицы пользователей (и, возможно, тем)?
Есть ли у меня отдельные классы, которые заполняют каждый из соответствующих атрибутов одним запросом? Если да, то как мне это сделать?
Из-за того, как написаны мои классы, основываясь на том, что меня учили, мой метод обновления строки DB или метод вставки просто принимают атрибуты в виде массива и обновляют все это, если у меня есть дополнительные атрибуты из других таблиц DB в каждом тогда как мне переписать эти методы, так как автоматическое обновление автоматически приведет к ошибкам?

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

Редактировать:

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

Answer 1

Были написаны целые книги о том, как спроектировать набор классов в соответствии со схемой базы данных.

Короче говоря: не существует единого универсального способа сделать это, вы должны принять множество проектных решений относительно компромиссов, которые вы хотите сделать, для каждого приложения. *

Вы можете найти библиотеку или структуру, чтобы помочь, ключевые слова: ActiveRecord, ORM (Object Relational Mapper)

P.S. Вы не представляете, что может привести к параличу анализа убийственной души и к чрезмерному проектированию. Сделайте самое простое, что может сработать для вашего приложения.

Пример кода для моего (ниже) комментария:

$post = new PublishedPost($data);
$edit = $post->setTitle($newTitle);
$edit->save();

Answer 2

Это слишком широкий вопрос, чтобы на него можно было ответить, не вдаваясь в эпическую длину.

По сути, существует четыре известных архитектурных шаблона источника данных из Шаблонов архитектуры предприятия : Шлюз табличных данных , Шлюз данных строк , Активная запись и Data Mapper . Их можно найти реализованными в общих php-фреймворках в некоторых вариациях. Это легко понять и реализовать.

Трудность возникает, когда вы начинаете решать проблему несоответствия импеданса между базой данных и бизнес-объектами в вашем приложении. Для этого существует ряд шаблонов объектно-реляционного поведенческого поведения, структурных и метаданных, таких как Identity Maps, Lazy Loading, Query Objects, Repositories и т. Д. Объяснение этого выходит за рамки. Они охватывают почти 200 страниц в PoEAA.

Вы можете посмотреть на Doctrine или Propel - два наиболее известных PHP ORM - которые реализуют большинство из этих шаблонов и которые вы можете использовать в вашем приложении, чтобы заменить текущую обработку доступа к базе данных.

Answer 3

На многие ваши проблемы можно ответить, проверив существующие решения, найденные в хорошо протестированных средах, таких как CakePHP , symfony и Zend Framework . Изучение их подходов и заглядывание под капот должно пролить свет на ваши вопросы. Кто знает? Вы можете даже решить написать будущие проекты, используя их!

Они потратили годы, собирая головы, чтобы решить эти проблемы. Воспользуйтесь!

Answer 4

Оформить заказ Учение:

Вот пример приложения на форуме, использующего Doctrine.

http://www.doctrine -project.org / документация / ручной / 1_2 / о / реальный мир-примеры # Форума-приложение