Estoy trabajando en un Proyecto Symfony 2.3 que utiliza el ORM de Doctrine 2. Como es de esperar, la funcionalidad se divide y se agrupa en paquetes mayormente independientes para permitir la reutilización del código en otros proyectos.

Tengo un UserBundle y un ContactInfoBundle. La información de contacto se divide porque otras entidades podrían tener asociada la información de contacto, sin embargo, no es imposible que se pueda construir un sistema donde los usuarios no requieren dicha información de contacto. Como tal, preferiría mucho que estos dos no compartan enlaces duros.

Sin embargo, la creación de la asignación de asociación de la entidad Usuario a la entidad ContactInfo crea una fuerte dependencia de ContactInfoBundle, tan pronto como el paquete se deshabilita, Doctrine produce errores que ContactInfo no está dentro de ninguno de sus espacios de nombres registrados.

Mis investigaciones han descubierto varias estrategias que deben contrarrestar esto, pero ninguna de ellas parece completamente funcional:

Doctrine 2's ResolveTargetEntityListener

Esto funciona, siempre que la interfaz se reemplace en el tiempo de ejecución. Debido a que se supone que la dependencia del paquete es opcional, podría ser que NO haya una implementación concreta disponible (es decir, contactInfoBundle no está cargado)

Si no hay una entidad objetivo, toda la configuración se colapsa sobre sí misma porque el objeto de marcador de posición no es una entidad (y no está dentro del espacio de nombres / Entidad), uno podría teóricamente vincularlos a una entidad simulada que realmente no hace nada. Pero esta entidad obtiene su propia tabla (y se consulta), abriendo una nueva lata de gusanos.

Invertir la relación

Para ContactInfo, lo más sensato es que el Usuario sea el lado propietario, lo que convierte a ContactInfo en el lado propietario eludiendo con éxito la parte opcional de la dependencia siempre que solo estén involucrados dos paquetes. Sin embargo, tan pronto como un tercer paquete (también opcional) desea un enlace (opcional) con ContactInfo, hace que ContactInfo se convierta en una dependencia fuerte de ContactInfo en el tercer paquete.

Hacer que el lado propietario sea lógico es una situación específica. Sin embargo, el problema es universal donde la entidad A contiene B y C contiene B.

Utilizar herencia de tabla única.

Siempre que los paquetes opcionales sean los únicos que interactúen con la asociación recién agregada, otorgará a cada paquete su propia entidad de usuario que extiende UserBundle \ Entities \ User podría funcionar. Sin embargo, tener varios paquetes que extienden una sola entidad hace que esto se convierta en un desastre. Nunca puedes estar completamente seguro de qué funciones están disponibles, y hacer que los controladores respondan de alguna manera a los paquetes que están activados y desactivados (como es compatible con la mecánica de inyección de dependencias de Symfony 2) se vuelve en gran medida imposible.

Cualquier idea o idea sobre cómo evitar este problema son bienvenidas. Después de un par de días de chocar contra las paredes de ladrillo, me he quedado sin ideas. Uno esperaría que Symfony tuviera algún método para hacer esto, pero la documentación solo aparece con el ResovleTargetEntityListener, que es sub-óptimo.