PHP OO - как инициализировать ваши бизнес-объекты?

Question

Под бизнес-моделью или бизнес-объектами я подразумеваю простые старые объекты, такие как «Пользователь» со всеми их свойствами name, address, ...; в дополнение ко всем свойствам пользователя, скажем, у каждого пользователя будет объект «AppointmentBook», у каждой книги есть набор объектов «TimeSlot» и т. д. Бизнес-модель имеет объекты со ссылками между ними, по крайней мере, так я кодирую бизнес-модель в Java. Здесь возникает вопрос:

Чтобы инициализировать мои бизнес-объекты, в Java я бы

1. получить все данные из БД только один раз во время применения инициализация
2. сопоставить данные из моей БД с моими бизнес-объектами
3. хранится в памяти (карты), и они будут распределены по всем запросам.

PHP Share-Nothing-Architecture сбивает меня с толку для правильного ОО-программирования: Если бы я использовал ту же логику, мне пришлось бы получать все объекты из БД, для каждый запрос (я знаю, что я все еще могу кешировать, но вы не кешируете всю свою БД, это не вопрос о кешировании, а скорее о способах программирования на PHP и его архитектуре).

Итак, допустим, что для одного HTTP-запроса мне просто нужны свойства пользователя, и мне не нужен доступ к его книге назначений. Было бы жалко получить все данные из БД для всех объектов, на которые ссылается Пользователь, поскольку мне просто нужны его свойства. Это означает, что я буду инициализировать объекты PHP из моей модели с большим количеством значений NULL (NULL из-за объектов, содержащихся в User, которые я не буду загружать), что в дальнейшем может привести к ошибкам.

Мне было интересно, как профессиональные PHP-разработчики обычно используют свои бизнес-объекты? (Я с Явы)

---

ОБНОВЛЕНИЕ: Было бы глупо говорить, что я загружаю всю базу данных в память во время инициализации приложения в Java. Я скорее имел в виду, что если мне нужно выбрать конкретного пользователя, я мог бы просто загрузить всех его данных, и это было бы доступно через все запросы.

Answer 1

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

Если я использую ту же логику, мне придется выбирать все объекты из БД для каждого запроса

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

Итак, давайте скажем, что для одного HTTP-запросаМне просто нужны свойства пользователя, и мне не нужен доступ к его книге назначений.

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

Если вам действительно нужны эти назначения, вы можете получить их из базы данных позже.

Это означает, что я буду инициализировать объекты PHP из моей модели с большим количеством значений NULL (NULL из-за объектов, содержащихся в User, которые я не буду загружать), что в дальнейшем может привести к ошибкам.

Не совсем, если это так, ваш объект User слишком велик.Чтобы сделать его меньше, вы должны загрузить весь пользователь.За исключением, конечно, пользователь должен быть достаточно маленьким, чтобы вы могли разумно загрузить его.

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

Answer 2

В PHP вы не храните в памяти все данные бизнес-модели вашего домена.Вместо этого вы запрашиваете только у БД (хотя кеш, если необходимо), данные, которые вы хотите.

Слой модели в php должен быть построен из нескольких доменных объектов и картографов данных (я предполагаю, что эта часть не так уж отличается отДжава ).Если вам нужны User данные, то вы получаете только эту информацию из базы данных / кэша.Скорее всего, у вас будет отдельный картограф только для работы с пользователями.

Вы отображаете информацию об этом пользователе и забываете о запросе.Следующий запрос (когда и если он придет) потребует другой информации.Может быть, вы захотите ContactList для этого User ... тогда вам действительно не нужен сам пользователь, только его user_id.Опять же, вы позволяете мапперу извлекать данные в объект домена, отвечающий за обработку списка контактов, и, если список контактов содержит User экземпляров, то просто создайте их, но оставьте в «неотключенном» состоянии (объект знаеттолько собственный user_id).Извлекайте их, только если вам действительно нужно, и только те части, которые вы будете использовать в этом «представлении».

---

PS У вас могут быть уведомления, я сказал, что модель должна быть сегментированным, но довольно часто разработчики php просто создают отдельный класс для каждой таблицы БД (который реализует ActiveRecord) и называют его «моделью».Это результат влияния Ruby on Rails на разработчиков php-фреймворка, что, IMHO, является одним из худших событий, произошедших с PHP за последние 5 лет.

Answer 3

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

Ваши модели должны быть "умными", чтобызагрузить данные из постоянного хранилища, которые необходимы для выполнения запрошенного действия.Для этого требуется, чтобы объект был достаточно «умным» для отложенной загрузки данных.

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

Существуют и другие шаблоны, которые могут удовлетворить ваши потребности в зависимости от типа приложения, однако Модель предметной области вместе с Data Mapper довольно гибкая.

Примерным средством отображения данных в мире PHP является Doctrine .