¿Cómo organizas tus paquetes en proyectos de Symfony2?

Question

tengo la pregunta exacta que este tipo tiene: http://groups.google.com/group/symfony2/browse_thread/thread/cd35132cc6972f29

Voy a copiar y pegar aquí:

Me preguntaba qué diferentes maneras de organizar los paquetes dentro de un proyecto personas están utilizando.

Parece que termino con un paquete masivo para un proyecto o un lote de paquetes que están estrechamente relacionados (dependientes) entre sí. p.ej;

Implementé mi propia entidad de usuario y formularios de inicio de sesión, etc., pero los usuarios están vinculados a una organización (con alguna funcionalidad). Etc ... Es en su mayoría las entidades que se superponen mucho, supongo ...

¿Los dividieron o volcaron todos en el mismo paquete?

Answer 1

Para cada proyecto, empiezo con un CoreBundle, donde pongo todo junto. Luego solo desarrollo funciones y a medida que pasa el tiempo lo vuelvo a evaluar: si alguna vez podría usar esta característica en otro lugar (o incluso liberarla para abrirla), la moveré a un nuevo paquete.

"tamaño" de la característica digna de paquete separado en realidad no importa - que he visto paquetes del sistema operativo tan grandes como un archivo js individual 1: D

una cosa es segura - el relleno de todo en un solo paquete es malo, va en contra de la razón por la cual esta arquitectura se implementó en primer lugar!

Answer 2

Mi respuesta en el siguiente tema probablemente le puede ayudar: Symfony 2 : Location of Entities

No soy un maestro de Symfony2, pero creo que tengo una idea bastante buena del diseño del bulto; por supuesto, no hay una respuesta universal pero puede seguir algunas "mejores prácticas".

Antes que nada, no creo que los grandes paquetes sean una buena solución; ya no divide su proyecto en aplicaciones, como lo hizo con Symfony1.4. Puede preguntar "¿pero qué puedo hacer con la lógica de frontend/backend?" ; bastante fácil, usa el controlador!

Cada paquete debe hacer referencia a un módulo, una piedra en el muro de su proyecto. Tienes que dividir tu aplicación; muchos paquetes no están mal. Por supuesto, no hagas un paquete para cada entidad, eso sería una pérdida de tiempo. Pero imagine una aplicación de blog: tendría un paquete de usuarios, paquete de artículos (que administraría publicaciones, categorías, ...), finalmente un paquete para páginas estáticas, ...

No es poco lógico que su paquete esté vinculado ; está creando una aplicación completa, por lo que en este caso están vinculados. Pero la palabra clave aquí es "generalización"; su paquete debe poder vincularse a otros paquetes, no solo el suyo. Debería poder reutilizarlo en otros proyectos.

¡Buena suerte!

Answer 3

Editar: I don't use bundles for app-specific code anymore.

---

Personalmente prefiero tener un paquete por una sección de una aplicación.Por ejemplo:

• UserBundle
• BlogBundle
• ForumBundle
• JobBundle
• StoreBundle
• etc

Esto está bien si la aplicación es una mezcolanza de varias funcionalidades, ninguno de los cuales es lo suficientemente grande como para requerir una aplicación separada y/o un subdominio . Pero si yo estaba desarrollando un gran applicaton tienda web, mis paquetes serían más específica:

• UserBundle
• ProductBundle
• CartBundle
• SearchBundle
• WishlistBundle
• etc

Entonces, yo diría que depende del enfoque del proyecto. Lo que es solo una sección para un proyecto podría ser la funcionalidad central de otro.

Y por lo general tienen CommonBundle, donde toda la materia común va, como CSS global, imágenes, diseños, etc.

También hay al menos dos opciones para la organización de back-end:

1. cada paquete tiene su propia sección backend, o
2. hay un gran paquete de back-end.

Personalmente me inclino por la primera opción y se puede leer sobre él en mi previous answer, pero hay personas que prefieren tener un paquete separado para todo el back-end - probablemente utilizando uno de los admin bundles.

Por cierto, está perfectamente bien que los paquetes estén interconectados; no es necesario que sean independientes entre sí. Por ejemplo, JMSDiExtraBundle depende de la biblioteca metadata y JMSAopBundle, que a su vez depende de cg-library. Si intenta mantener los paquetes totalmente independientes, terminará con grandes cantidades monolíticas de códigos de paquete único.