Где и когда стоит использовать partial объекты doctrine?

Question

[Николай Егоров]

Здравствуйте!

В процессе изучения Симфони возникла необходимость загрузки из БД 40-50 объектов с 5-6кб текста. Эти объекты загружаются на каждой странице сайта - категорий и теги. Да, у каждого тега и категории есть текст до 5-6кб, но этот текст выводится только для активной категории/тега - остальные, соответственно, просто нагружают сервер. Я сделал отдельный метод в репозитории, который бы возвращал не все данные категории, а только необходимые:

$query = $qb
            ->select('c.id, с.title, с.slug')
            ->getQuery();
        return $query->getResult();

В итоге я получил массив, а не объекты типа Category - так я узнал, что чтобы получить частично загруженный объект, необходимо использовать механизм Doctrine частичной загрузки объектов, у которого есть особенность - если после этого запросить уже загруженный PARTIAL объект, то доктрина вернет его же, а не полноценный.

Получается, что для увеличения производительности можно использовать два метода:
- простые массивы
- и Partial объекты.

В админке, в том проекте который я сейчас делаю, я не вижу пока смысла сильно беспокоиться о производительности - нет там и такого трафика, и списка категорий на каждой странице. Так что там, я буду использовать полностью загруженные объекты.

А вот с публичной частью хочется и о производительности подумать, и просто разобраться в теме - что лучше использовать в подобных случаях: массивы, или partial объекты?

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

Подскажите, пожалуйста:
1. В каких случаях вы используете Partial объекты?
2. Используете ли массивы и в каких случаях?

Спасибо!

Answer 1

[voronkovich]

На мой взгляд их лучше не использовать вообще.

1. Эта идея была взята из Hibernate. Но, Java позволяет в последствии сделать дозагрузку данных которые не были загружены изначально. Т.е. использование partial objects не может привести к ошибке. В PHP у объектов нет API аналогичного Java. У меня есть подозрение, что именно поэтому partial objects будут убраны из Doctrine 3, как это стало с поддержой операций detach/merge.

2. Реализация partial objects в Doctrine противоречит принципу "Модель всегда должна быть валидна"

Кстати, вы забыли про вариант с использование легковесного DTO (см. паттерн Flyweight), вместо массивов. См. https://www.doctrine-project.org/projects/doctrine...

Когда можно использовать массивы?

Массивы легко сериализуются, например, с ними можно быстро сделать API:

public function api(EntityManagerInterface $entityManager): Response
{
    $posts = $entityManager->createQuery('SELECT p FROM App\Entity\Post p')->getArrayResult();

    return new JsonResponse($posts);
}

Comments

[Николай Егоров]

Спасибо Вам за подсказку по поводу использования DTO! Я не знал даже об этом. Я сделал DTO объект без сеттеров с приватными свойствами - таким образом его можно использовать только в выводе. Попробовал - очень понравилось - и объекты используются, и без загрузки из БД ненужных данных!

Правда я не совсем понял причем тут паттерн Flyweight. Возможно доктрина его использует при создании DTO объектов, но это лишь моя догадка ))

В любом случае спасибо за помощь!

[voronkovich]

Николай Егоров, Я имел ввиду, что используя DTO, мы сами применяем шаблон Приспособленец. Хотя и не уверен, т.к. не сильно разбираюсь в шаблонах.

[Николай Егоров]

voronkovich, ну так или иначе вы мне помогли - спасибо! ))

А метод репозитория, который возвращает не entity, а DTO, нужно явно называть типа findCategoryDTOforMenuBuild()? Или "DTO" лучше не указывать явно?

[voronkovich]

Николай Егоров, Я бы не стал указывать DTO явно. Если бы вы использовали гидратацию в массивы, вы вряд ли бы стали именовать метод: findCateroryArrayForMenuBuild?

[Николай Егоров]

voronkovich, логично!