Pull to refresh

Comments 6

1) В вендорных бандлах лучше не использовать аннотации для мэпинга сущностей. Лучше yaml, это позволит прописать мэпинги для Doctrine ORM и ODM к примеру.
2) Стоило вынести всю логику по работе с доктриной в отдельный сервис-менеджер. В дальнейшем можно было бы вынести интерфейс и добавить реализации для ODM или других ORM ну или дать возможность разработку заимплементить интерфейс менеджера для своего хранилища.
3) flush в контроллере без передачи списка того что вы хотите зафлашить это не хорошо, особенно когда речь идет о бандле, который будут использовать сторонние разработчики. Возможно в этом случае ничего страшного, но по хорошему опять же стоит это дело выносить в сервис менеджер и оставить бандл вообще без контроллеров, оставив это дело опять же на откуп разработчику. Контроллеры можно конечно добавить, в виде примера или если они реально могут реюзаться, но тогда правила маршрутизации стоит опять же выносить в yaml полностью.
3) Считаю в вашем случае завязываться на doctrine_extensions лишним, хотя если вам так удобнее то что поделать.
4) Раз уж реализовали класс для сонаты, стоило добавить его в рекомендуемые пакеты. Но это уже мелочи.
1) и 3) Я когда-то сделал этот бандл для себя, и я как-то исторически использую аннотации. Уже потом я решил его использовать для демонстрации в этой статье. Если бы я изначально делал публичный бандл, то я бы, конечно, сделал бы маппинг на yaml.
2) Вся логика вынесена из бандла, в нём вообще нет контроллера, во второй части контроллер перенесён в другой бандл. Поэтому нечего выносить в сервис. В первой части есть контроллер, но он предназначен для того, чтобы просто работало, я не стал сильно заморачиваться о нём, ведь в самом бандле его не будет.
4) согласен.
Основная часть статьи — третья и четвёртая, и частично вторая, а первая — чтобы было о чём говорить в остальной части. Мне бы следовало, наверное, указать, что код контроллера (и шаблоны, что уж там говорить) — не образцы для подражания. Я, например, в контроллерах своих рабочих проектов вообще отказался от ParamConverter и от аннотации Template.
Зачем создавать конструктор формы и передавать туда `dataClass`? Разве нельзя при создании формы передать в массиве с опциями этот самый `array('data_class' => $container->getPaeameter('lexxpavlov_page.entity_class'))`?
Во-первых, в родителе класса формы нет контейнера, и его туда в любом случае нужно передавать.
А во-вторых, передавать контейнер в сервис не очень правильно, потому что это идёт вразрез с самой идеей DI-контейнеров — уменьшать связность компонентов, а тут придётся в классе определять, где находятся нужные ему данные.
Поэтому в сервисы нужно уже готовые данные или другие сервисы. А передача через конструктор — это простейший способ передачи зависимости.
Естественно, что в классе формы не будет контейнера. Контейнер есть в контроллере.

$form = $this->createForm('lexxpavlov_page', $page); // ну вот тут третьим параметром передать этот data_class же можно
Это значение по умолчанию считайте. Вы всегда можете переопределить это дело при создании формы Другой вопрос, зачем это делать.
Sign up to leave a comment.

Articles