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

$filter = $filterForm->getData();
$images = $imageRepository->findEntities([], $filter['sortBy'], $filter['direction'], $page, 10);

filterable grid of items using Shuffle.js
multiple-filter-masonry

Работа с БД идет в репозиториях.

То есть иерархия такая:

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

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

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

Вы имеете ввиду HttpKernel? Тогда начните с документации: https://symfony.com/doc/current/components/http_ke... :)

В Symfony всего три компонента (на мой взгляд), которые и составляют "ядро":

• HttpKernel
  
• HttpFoundation
  
• EventDispatcher
  

В кратком изложении можете про них почитать тут: https://gnugat.github.io/2016/02/03/ultimate-symfo...

Я проникся ООП когда писал одну программулину в процедурном стиле и внезапно понял что не могу разобрать свой собственный код, написанный вчера. Потратил на рефакторинг 12 часов и после этого код стал больше похож на английский язык, чем на непонятный набор букв, точек, цифр и скобочек. Так что в идеале нужна практическая задача на чистом языке, без фреймворков.
Раз речь о PHP, попробуйте написать свою ORM. Простейший построитель запросов для CRUD, но универсальный. Как минимум наследование точно поймёте.
По паттернам я сейчас толкового курса сходу не нашёл, но не переоценивайте их значимость. Лучше почитайте (посмотрите видео) о том, что такое SOLID.
Когда придёт понимание что такое наследование и зачем оно нужно, тогда можно и про паттерны почитать, но как по мне, реально интересен только Одиночка. Все остальные это просто правильные способы применить наследование, и выглядят довольно очевидными.

s0lar, JoinColumn и Column - несовместимые аннотации, одна другую затирает. Чтобы правильно работал EntityType у поля надо прописать связь ManyToOne или OneToOne.

Сделайте сервис, который сможет отдавать нужные вам данные по запросу нужного метода.
И заинжектите сервис в twig.
В config.yml:

twig:
    globals:
        your_service: '@your_service'

В twig можно просто дергать {{ your_service.someMethod() }}

Немного документации.

Использовать нужно первый вариант. В нем мы реализуем паттерн внедрение зависимостей (dependency injection), в то время как во втором случае - паттерн (скорее даже, анти) - локатор служб (service locator). Локатор служб скрывает зависимости классов/методов и создает излишнюю связанность кода, который теперь зависит от этого самого контейнера. Становится неудобно мокать зависимости для тестирования.

Если очень хочется именно массив сущностей:

public function getImages()
{
   return $this->images->toArray();
}

Но в таком случае вы лишаетесь преимуществ доктриновской коллекции. Особенно это заметно при ленивой загрузке.

По остальному:

1. Выворачивать ссылку на коллекцию в гетерах(делать return $this->images;) - неочень.
   Используйте return clone $this->images;
   
2. setProductId() и подобные в вашем классе картинки бесполезен, у вас уже есть реляция.
   
3. Может быть в тему в вашем случае - Extra Lazy Associations
   

1) ссылки с картинки на продукт не срут память, ибо объект продукта один и все картинки ссылаются на один объект. лишней памяти не тратится.

2) по поводу сложности. да оно кажется избыточным, но нужно чтобы было удобно потом работать с ними, добавлять новые связи, ленивая загрузка и тд.
просто сущности вы не получите, но если нужен только вывод то можно вместо getRepository / find сделать например createQuery / fetchArray. но это будет массив без вложенных сущностей, то есть картинок у продукта автоматически не будет.

3) вместо $em->getRepository('AppBundle:Product')->findById(1);
лучше $em->getRepository('AppBundle:Product')->find(1);
или даже $em->find('AppBundle:Product', 1);