Как вы организуете свои пакеты в проектах Symfony2?

У меня есть точный вопрос, который у этого парня есть: http://groups.google.com/group/symfony2/browse_thread/thread/cd35132cc6972f29

Я просто скопирую его здесь:

Мне было интересно, какие способы организации пакетов в рамках проекта люди используют.

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

Я реализовал свои собственные пользовательские сущности и формы входа и т. Д., Но пользователи связаны с организацией (с некоторыми функциями). Etc … Это в основном сущности, которые много перекрывают, я думаю …

Вы, ребята, разделили их или свалили все в одном комплекте?

Изменить : я больше не использую пакеты для кода, специфичного для приложения .


Лично я предпочитаю иметь пакет в одном разделе приложения. Например:

  • UserBundle
  • BlogBundle
  • ForumBundle
  • JobBundle
  • StoreBundle
  • и т.д

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

  • UserBundle
  • ProductBundle
  • CartBundle
  • SearchBundle
  • WishlistBundle
  • и т.д

Итак, я бы сказал, это зависит от фокуса проекта. То, что только раздел для одного проекта может быть основной функциональностью другого.

И у меня обычно есть CommonBundle , где все общие вещи идут, как глобальный CSS, изображения, макеты и т. Д.

Также есть, по крайней мере, два варианта для бэкэнд-организации:

  1. каждый комплект имеет свою внутреннюю часть или
  2. есть один большой бэкэнд-пакет.

Лично я склоняюсь к первому варианту, и вы можете прочитать об этом в моем предыдущем ответе , но есть люди, которые предпочитают иметь отдельный пакет для всего бэкэнд – возможно, используя один из пакетов админов .

Кстати, прекрасно, что связки должны быть взаимосвязаны – вам не нужно делать их независимыми друг от друга. Например, JMSDiExtraBundle зависит от библиотеки метаданных и JMSAopBundle , что, в свою очередь, зависит от cg-библиотеки . Если вы попытаетесь сохранить целостность пакетов, вы получите большие монолитные однокомпонентные комки кода.

Для каждого проекта я начинаю с одного CoreBundle, где я собираю все вместе. Затем я просто разрабатываю функции в нем, и со временем я переоцениваю это – если я когда-нибудь воспользуюсь этой возможностью (или даже выпустю с открытым исходным кодом), я переведу ее в новый пакет.

«Размер» функции, стоящей в отдельном пакете, не имеет большого значения – я видел, что пакеты ОС размером с один одиночный файл js: D

Одно можно сказать наверняка – набивка всего в одном комплекте плохо, это противоречит всей причине, почему эта архитектура была реализована в первую очередь!

Мой ответ в следующем разделе, вероятно, поможет вам: Symfony 2: Местоположение объектов

Я не мастер Symfony2, но я думаю, что я неплохо разбираюсь в дизайне пакета; конечно, нет универсального ответа, но вы можете следовать некоторым «лучшим практикам».

Прежде всего, я не думаю, что большие пакеты – хорошее решение; вы больше не разбиваете свой проект на приложения, как вы это делали с Symfony1.4. Вы можете спросить «но что я могу сделать с логикой frontend / backend?» ; довольно просто, используйте контроллер!

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

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

Удачи !