Paquetes Symfony2: ¿los estoy usando, ¿verdad?

Question

Tengo una aplicación que está desarrollada en Symfony2. Ahora la estructura para ello es la siguiente:

• FrontBundle - incluye todo lo relacionado con la opinión de la aplicación y la interfaz de usuario.
• PersistenciaBundle - incluye todo lo relacionado con la capa de persistencia de la aplicación.
• DomainBundle - incluye todo lo relacionado con las entidades de la aplicación y los servicios.

¿Esta estructura está bien? O paquetes se utilizan como característica foro - ForumBundle - que incluye todas las capas (controladores, servicios, la lógica de dominio y persistencia ) relacionados con el foro.

Answer 1

No existen reglas fijas sobre cómo estructurar su aplicación utilizando paquetes, pero esto es lo que encontré después de desarrollar en Symfony2 durante casi un año.

Utilice un paquete específico de la aplicación. Al principio, started con múltiples haces como CommonBundle, UserBundle, MainBundle, BlogBundle, ContactBundle, etc. que resultó ser no tan conveniente en el extremo, por lo que cambió a una sola aplicación haz específico - AppBundle.

Puede organizar su código ordenadamente mediante espacios de subnombres. Por ejemplo, los controladores de back-end irían al espacio de subnombres AppBundle\Controller\Backend.

Tenga en cuenta que estoy hablando de un paquete específico de la aplicación - esas cosas que son exclusivas de la aplicación concreta y que no tienen sentido para su reutilización en otro lugar. Todavía puede desarrollar paquetes separados para cosas reutilizables y ponerlos en la infraestructura de proveedores.

Guarde las cosas que no sean de Symfony en paquetes. No es necesario tener un paquete para el modelo y las clases Service Layer en un paquete si no son específicas de Symfony2. Vea this question y mi respuesta para más detalles.

Answer 2

Existen diferentes formas de organizar la estructura de las aplicaciones para sus proyectos. Pero si desea distribuir sus paquetes y seguir las mejores prácticas de Symfony, los paquetes son más funciones que la separación de la interfaz de usuario. Más sobre los paquetes leídos en documentation.

tengo dos proyectos con las siguientes estructuras, ambas válidas pienso:

1. haciendo un paquete para cada característica: BlogBundle, StoreBundle y así sucesivamente, y AppBundle que contiene la materia en general. Sin Backend/Frontend separación. Es SaaS donde el backend es frontend en la mayoría de los casos.
2. Un paquete para frontend, uno para back-end. Comparten solo entidades y cosas específicas del dominio. La aplicación tiene dos fines diferentes.

Answer 3

Como dijo Elnur, usar una AppBundle es una buena práctica.

Un solo paquete implementa el patrón MVC por sí mismo, así que creo que no es una buena idea usar paquetes para separar las capas.

Creo que la mejor manera de usar paquetes es pensar "código abierto". Si la función que está desarrollando es lo suficientemente genérica como para que la publiquen todos o para que se reutilice en un proyecto futuro, coloque esta característica en un paquete. De esta manera le obligará a crear la función sin ninguna regla comercial que pertenezca a su AppBundle.

paquetes son ladrillos