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

Question

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

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

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

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

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

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

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

Не желая быть ложкой, просто подтолкнуть в правильном направлении. Благодарю.

Answer 1

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

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

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