Andrey Kulikovsky

Если выгружать сущности полностью:

$query= $this->
            ->createQueryBuilder()
            ->select('b, users')
            ->from(B::class, 'b')
            ->join('b.users', 'users')
            ->where('b.id = :id')
            ->setParameter('id', $id)
            ->getQuery();

Обращаем внимание на строчку select('b, users')

PS. И Doctrine довольно сложный инструмент, как выше советуют - читайте документацию.

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

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

Для большинства сайтов и несложных проектов active record - хороший вариант. Для сложных проектов - Doctrine.

Про использование orm vs pdo выше ответил OnYourLips

1. Никаких сеттеров. Entity всегда дожна быть валидной (установка значений через конструкторы, именованные контсрукторы). Если нужно менять состояние - делаем осмысленные методы, типа:
   

   public function updatePassword($plainPassword, EncoderInterface $encoder) {
       //...
   }
   public function updateProfile(UserProfile $profile) {
       //...
   }

   
   
2. Вадидация должна происходить в приложении на более высоких слоях. (Валидируем request, command и прочее).
   
3. Очень удобно использовать Embedded-object (doctrine-orm.readthedocs.io/projects/doctrine-orm/... в качестве Value-objects.
   
4. flush() всегда делаем в контроллере (в верхнем слое приложения) и забываем про такую конструкцию $em->flush($myEntity); Суть такая: наше приложение работает с бизнес-объектами (domain-objects), меняет их состояние, однако про сохранение (коммит изменений) слой модели не должен знать, это не его задача. Все изменения фиксируются в конце запроса.
   
5. Используйте Domain-events - очень удобная штука.
   
6. Иногда очень полезно отказаться от автогенерации доктриной id, можно использовать uuid.
   

И дострина многим не нужна, часто достаточно active-records.
Doctrine даёт большой профит только если доменна логика сложная, ну все это хорошо ложится на проектирование по модели (DDD).

Для таких целей лучше использовать события. А лучше domain-event.
Пример тут: https://github.com/fesor/domain-events

Такой запрос как раз и делает, что вы описали.

$articles = $em->createQuery($dql)->getResult();

Получается массив Article[] с привязанными комментариям к сущности Article

Про память, для выборок на фронте вызвращайте скальярный результат getScalarResult (тупо массив или делайте dto, если нужны красивые объекты), Proxy-объекты entity довольно тяжелые.

Proxy-объекты оптимально использовать для бакэнда (кабинеты пользователя, админка и прочее управление).