Состав пакета Symfony, как структурировать мой код при использовании нескольких пакетов

Question

Мне нужно несколько советов о том, как структурировать мое приложение Symfony 2.0.Если у меня есть несколько комплектов (Cart Bundle, Product Bundle, CMS Bundle) и я хочу использовать аспекты всех этих комплектов при составлении своей страницы, как мне лучше всего это сделать?

Я могу представить два способасделайте это, но я ищу руководство, по которому (если и то, и другое) правильно.

1) Предоставьте доступ ко всем функциям моих пакетов через сервисы и сделайте эти сервисы доступными для использования непосредственно из ветки.Таким образом, я могу передать свой запрос на маршрутизацию наиболее подходящему пакету (поэтому http://myclient.org/User/Account) передается в пакет ClientUser для обработки, но базовый шаблон с мини-корзиной покупок в навигации может получить доступ к информации, которую оннеобходимо непосредственно из ветки (мне не нужно передавать это)

2) Создайте пакет, который получает доступ ко всем другим пакетам для создания страницы (например, VendorFrontend или VendorBackend).Это будет означать, что ВСЕ запросы маршрутизации будут переданы в этот пакет, и этот пакет будет получать доступ к необходимой информации для каждой части страницы перед передачей в шаблон.

Первый вариант кажется неправильным, потому что я неВы уверены, что можно даже разрешить Twig напрямую использовать сервисы (хотя и контейнер сервисов)?

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

В этом примере я пытаюсь создать очень простой сайт электронной коммерции только для демонстрационных целей.У меня есть базовый шаблон, который будет иметь основную навигацию, мини-корзину, «тело» и нижний колонтитул.Я храню это в каталоге / app / Resources.Я планировал, чтобы все другие шаблоны наследовали этот и переопределяли область «тела».

Не похоже, чтобы вас обманывали, просто толчок в правильном направлении.Спасибо.

Answer 1

Я думаю, что важно отойти от идеи, что для генерации «страницы» необходимо собрать вместе все переменные, которые могут потребоваться шаблону, чтобы отобразить, а затем передать их в шаблон. Контроллер должен делать только конкретную вещь для запроса, который он обслуживает, и не более. Поэтому, если в URL-адресе указан конкретный продукт, извлеките продукт и передайте его в шаблон. Если есть ссылка на конкретный продукт, но он не существует или не должен отображаться, вы отвечаете 404/410 / что угодно. Если есть конкретная коллекция, извлеките коллекцию и передайте ее. Маршрутизатор / контроллер должен декодировать запрос - сам URL, метод HTTP и т. Д. - и преобразовать его в нечто конкретное. Ничего общего и не относящегося к конкретному запросу, здесь не принадлежит.

Также важно, я бы сказал, абстрагироваться как можно лучше от комплектов, которые вы используете из шаблонов Twig. Я больше выступаю за то, чтобы шаблоны «вытягивали» в них то, что им нужно, а не вставляли, но это достигается определением функций Twig внутри пакетов, которые сами могут через контейнер DI подключаться к данным, которые могут или не могут быть быть в текущем запросе и т. д. Таким образом, вы создаете функцию Twig, которая может принимать в качестве параметра все, что может измениться - если это связано с категориями продуктов, пусть она принимает в качестве параметра объект категории продуктов.

По сути, ответ больше 1), чем 2), но вы не должны получать доступ к сервисам напрямую через Twig - вы должны использовать прокси с помощью функций, которые имеют смысловой смысл в шаблоне, которые сами по себе определены для того, чтобы сервисы вводились в них во время выполнения - сервисы, которые вы можете по-разному определять в любых новых пакетах, которые вы включаете или пишете.