Что должен представлять пакет в Symfony2?

Ответ 1

Я также новичок в Symfony и буду с интересом следить за результатами этого вопроса, но для чего он стоит, я беру на себя это:

Пакет просто: группа файлов, активов, классов и методов PHP, тесты и т.д. Логикой группировки может быть любое, что угодно. В некоторых случаях действительно очевидно, что такое группировка и почему это было сделано - например, если я написал систему блога для Symfony2 и хотел ее выпустить, я бы превратил ее в пакет. Этот пример больше всего использовался в документации.

Но вы также можете использовать пакеты для всего, что хотите разблокировать, как одну небольшую функцию. Скажем, например, этот комплект, который создает маршруты по умолчанию для всех ваших контроллеров. Это не полностью разработанный плагин/функция, такая как блог или форум, но это немного код, который я могу легко импортировать в свой проект, он остается полностью отделенным от всего остального, это набор.

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

Взять вашу конкретную ситуацию:

Быстро и просто:

• MySite\MyCode - выполняет свою работу, и, возможно, у вас нет логического способа разбить код, который вы собираетесь писать.

Если есть несколько уникальных особенностей между двумя сайтами, и вы хотите их разделить для ясности:

• MySite\SharedFeatures
• MySite\Site1Features
• MySite\Site2Features

Если вам действительно нравится все на своем месте или если у вас сложный проект, возможно:

• MySite\MySiteMain (общие функции и всевозможные сборники, которые не заслуживают собственного пакета)
• MySite\News
• MySite\Site1FeatureSomethingOrOther
• MySite\Site2FeatureSomethingOrOther

Я определенно думаю, что вы хотите придерживаться логических групп кода, поэтому я думаю, что ваш пример "связывает Site1\News и Site2\News" и "MySite\Site1News и MySite\Site2News" не будет Лучше всего идти. Site1 и Site2 являются реализациями, поэтому создание отдельного пакета для каждой страницы новостей сайта кажется мне контрпродуктивным; вы хотите создать один компонент новостей и создать его для использования двумя разными способами.

Что касается вашего вопроса с двумя доменами, вы можете указать оба домена в одном коде и проверить в своем коде, для какого домена запрашивается, или вы можете проверить две копии одного и того же кода и изменить файлы конфигурации (это не обязательно нарушает идею DRY, поскольку вы все равно редактируете код в одном месте, а затем обновляете обе копии.)

Ответ 2

То, как я понимаю пакет, это то, что он похож на то, что CMS, например, например. Typo3 или Drupal вызывают "плагин". Поэтому он должен быть идеально автономным и написан таким образом, чтобы его можно было использовать и в других проектах.

например. в вашем случае я бы создал "staticHtmlBundle", который содержит все статические страницы вашего сайта, разделенные на site.com и dom2.site.com.

Затем я бы создал "newsBundle", который содержит все новостные статьи, может быть, даже с управлением базой данных с небольшим административным разделом, где вы можете редактировать их и назначать им по разным каналам (в вашем случае это site.com, dom2.site.com). Статическая страница из staticHtmlBundle будет вызывать newsBundle и отображать ее данные (например, listView новостей или detailView и т.д.).

Если вы сохраните все как абстрактное и многоразовое, то вы можете даже опубликовать newsBunde в репозитории Symfony 2 Bundle и поделиться им с сообществом!

Ответ 3

То, как я воспринимаю пакеты Symfony2, заключается в том, что они предоставляют модульную систему, которая позволяет не только расширять и переопределять PHP-код, но и любые ресурсы, которые они могут включать или не включать.

Сказав это, подумайте, что у вас есть API, и вы хотите передать объект.
Как вы это сделаете?

Конечно, вы можете сделать это вручную, но было бы неплохо, если Symfony может сделать это за вас?

Мой способ сделать это будет включать 3 пакета, JMSSerializerBundle и FosRestBundle.

• Один пакет для клиентской стороны - MyCompany/ClientBundle
• Один пакет для серверной части - MyCompany/ServerBundle
• В одном комплекте есть все объекты передачи данных, которые я хотел бы передать - MyCompany/CommonBundle.

Внутри моего MyCompany/CommonBundle у меня были бы классы, которые я использовал бы для своих объектов передачи данных, а также правила сериализации, которые я должен был бы предоставить JMSSerializerBundle. Они могут быть в виде аннотаций xml, yml или php.

Как только у вас есть объект, заполненный данными, вы можете просто использовать return, а FosRestBundle будет сериализовать его для вас. Сериализация будет зависеть от маршрутизации, поэтому вы можете иметь объект, сериализованный в XML для одной системы и в JSON для другого. Ключевым моментом является то, что у вас есть разные форматы сериализации и управление версиями, которые вы можете использовать в дальнейшем.

На стороне клиента вы можете использовать простой преобразователь параметров для преобразования полученного JSON или XML в объект прямо в контроллере без дополнительных проблем. Вы также можете ввести некоторые правила проверки, чтобы вы могли проверить, заполнен ли объект, как вы ожидаете.

В моем примере MyCompany/CommonBundle имеет объекты, которые будут использоваться несколькими приложениями и будут идентичны. Наличие в качестве отдельного пакета помогает избежать дублирования кода и упрощает долгосрочное обслуживание.

Надеюсь, мне удалось это объяснить. Есть вопросы? Спросите в комментариях. Будет соответствующим образом обновлен ответ.