Это может быть для вас очевидным, но, даже после прочтения многих руководств и блогов, я все еще не уверен, что именно должен представлять пакет на Symfony2 на веб-странице. И трудно угадать это из простых демонстрационных приложений.
Например: у меня есть сайт, который разделен на две части (один – это домен второго уровня, например example.com а другой – dom2.example.com ). Каждая из этих двух частей имеет свои собственные разделы – иногда одни и те же (например, новости) иногда разные.
Какое правильное представление этого в symfony2? Должен ли я
MySite\site1 и MySite\site2 а также различные разделы с помощью разных контроллеров или Site1\News и Site2\News , или MySite\Site1News и MySite\Site2News и т. д. … или я ошибаюсь в этом?
Я также новичок в Symfony и с интересом буду следить за результатами этого вопроса, но для чего он стоит, я беру на себя это:
Пакет просто: группа файлов, активов, классов и методов PHP, тесты и т. Д. Логикой группировки может быть любое, что вам нравится. В некоторых случаях, действительно очевидно, что такое группировка и почему это было сделано – например, если я написал систему блога для Symfony2 и хотел ее выпустить, я бы превратил ее в пакет. Это пример, который больше всего используется в документации.
Но вы также можете использовать пакеты для всего, что вы хотели бы выпустить, как одну небольшую функцию. Скажем, например, этот пакет, который создает маршруты по умолчанию для всех ваших контроллеров. Это не полностью разработанный плагин / функция, такая как блог или форум, но это немного код, который я могу легко импортировать в свой проект, он остается полностью отделенным от всего остального, это набор.
Наконец, вы также будете использовать пакеты внутри вашего проекта, абсолютно любым способом, который имеет смысл для вас.
Мое отношение к вашей конкретной ситуации:
Быстро и просто:
MySite\MyCode – выполняет свою работу, и, возможно, у вас нет логического способа разбить код, который вы собираетесь писать. Если есть несколько уникальных особенностей между двумя сайтами, и вы хотите их разделить для ясности:
MySite\SharedFeatures MySite\Site1Features MySite\Site2Features Если вам действительно нравится все на своем месте или если у вас сложный проект, возможно:
MySite\MySiteMain (общие функции и MySite\MySiteMain которые не заслуживают собственного пакета) MySite\News MySite\Site1FeatureSomethingOrOther MySite\Site2FeatureSomethingOrOther Я определенно думаю, что вы хотите придерживаться логических групп кода, поэтому я думаю, что ваш пример «пакеты Site1 \ News и Site2 \ News» и «MySite \ Site1News и MySite \ Site2News» не был бы лучшим способом. Site1 и Site2 – это реализации, поэтому создание отдельного пакета для страницы новостей каждого сайта представляется мне контрпродуктивным; вы хотите создать один компонент новостей и создать его для использования двумя разными способами.
Что касается вашего вопроса с двумя доменами, вы можете указать оба домена в одном коде и проверить в своем коде, для какого домена запрашивается, или вы можете проверить две копии одного и того же кода и немного изменить конфигурационные файлы (это не обязательно нарушает идею DRY, потому что вы все равно будете редактировать код в одном месте, а затем обновлять обе копии.)
Я понимаю, что это похоже на то, что CMS, например, Typo3 или Drupal, называют «плагином». Поэтому он должен быть идеально автономным и написан таким образом, чтобы его можно было использовать и в других проектах.
Например, в вашем случае я бы создал «staticHtmlBundle», который содержит все статические страницы вашего сайта, разделенные на сайтах site.com и dom2.site.com.
Затем я создаю «newsBundle», который содержит все новостные статьи, возможно, даже с управлением базой данных с небольшим административным разделом, где вы можете редактировать их и назначать им по разным каналам (в вашем случае это site.com, dom2. site.com). Статическая страница из staticHtmlBundle будет вызывать newsBundle и отображать ее данные (например, listView новостей или подробный просмотр и т. Д.).
Если вы сохраните все как абстрактное и многоразовое, то вы можете даже опубликовать newsBunde в репозитории Symfony 2 Bundle и поделиться им с сообществом!
То, как я воспринимаю пакеты 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 есть объекты, которые будут использоваться несколькими приложениями и будут идентичными. Наличие в качестве отдельного пакета помогает избежать дублирования кода и упрощает долгосрочное обслуживание.
Надеюсь, мне удалось это объяснить. Любые вопросы?
Спросите в комментариях. Соответственно обновит ответ.