У меня есть точный вопрос, который у этого парня есть: http://groups.google.com/group/symfony2/browse_thread/thread/cd35132cc6972f29
Я просто скопирую его здесь:
Мне было интересно, какие способы организации пакетов в рамках проекта люди используют.
Кажется, у меня есть либо один массивный пакет для проекта, либо множество связок, которые тесно связаны друг с другом. например;
Я реализовал свои собственные пользовательские сущности и формы входа и т. Д., Но пользователи связаны с организацией (с некоторыми функциями). Etc … Это в основном сущности, которые много перекрывают, я думаю …
Вы, ребята, разделили их или свалили все в одном комплекте?
Изменить : я больше не использую пакеты для кода, специфичного для приложения .
Лично я предпочитаю иметь пакет в одном разделе приложения. Например:
Это нормально, если приложение является mishmash из нескольких функциональных возможностей, ни один из которых не является достаточно большим, чтобы требовать отдельное приложение и / или субдомен. Но если бы я разрабатывал приложение для большого интернет-магазина, мои пакеты были бы более конкретными:
Итак, я бы сказал, это зависит от фокуса проекта. То, что только раздел для одного проекта может быть основной функциональностью другого.
И у меня обычно есть CommonBundle , где все общие вещи идут, как глобальный CSS, изображения, макеты и т. Д.
Также есть, по крайней мере, два варианта для бэкэнд-организации:
Лично я склоняюсь к первому варианту, и вы можете прочитать об этом в моем предыдущем ответе , но есть люди, которые предпочитают иметь отдельный пакет для всего бэкэнд – возможно, используя один из пакетов админов .
Кстати, прекрасно, что связки должны быть взаимосвязаны – вам не нужно делать их независимыми друг от друга. Например, JMSDiExtraBundle зависит от библиотеки метаданных и JMSAopBundle , что, в свою очередь, зависит от cg-библиотеки . Если вы попытаетесь сохранить целостность пакетов, вы получите большие монолитные однокомпонентные комки кода.
Для каждого проекта я начинаю с одного CoreBundle, где я собираю все вместе. Затем я просто разрабатываю функции в нем, и со временем я переоцениваю это – если я когда-нибудь воспользуюсь этой возможностью (или даже выпустю с открытым исходным кодом), я переведу ее в новый пакет.
«Размер» функции, стоящей в отдельном пакете, не имеет большого значения – я видел, что пакеты ОС размером с один одиночный файл js: D
Одно можно сказать наверняка – набивка всего в одном комплекте плохо, это противоречит всей причине, почему эта архитектура была реализована в первую очередь!
Мой ответ в следующем разделе, вероятно, поможет вам: Symfony 2: Местоположение объектов
Я не мастер Symfony2, но я думаю, что я неплохо разбираюсь в дизайне пакета; конечно, нет универсального ответа, но вы можете следовать некоторым «лучшим практикам».
Прежде всего, я не думаю, что большие пакеты – хорошее решение; вы больше не разбиваете свой проект на приложения, как вы это делали с Symfony1.4. Вы можете спросить «но что я могу сделать с логикой frontend / backend?» ; довольно просто, используйте контроллер!
Каждый комплект должен ссылаться на модуль, камень в стене вашего проекта. Вы должны разделить ваше приложение; многие пачки не плохие. Конечно, не делайте связку для каждого объекта, это будет пустой тратой времени. Но представьте себе приложение для блога: у вас будет пакет User, комплект статей (который будет управлять сообщениями, категориями, …), в конечном итоге пакет для статических страниц, …
Нелогично, что ваш пакет связан; вы создаете целое приложение, поэтому в этом случае они связаны. Но ключевым словом здесь является «обобщение»; ваш комплект должен быть связан с другими пакетами, а не только с вашими. Вы должны иметь возможность повторно использовать его в других проектах.
Удачи !