Ventajas y desventajas de usar eventos para mantener los controladores sincronizados en aplicaciones angulares complejas

¿Puede alguien darme algún consejo sobre las ventajas y desventajas de usar eventos para mantener diferentes partes de una aplicación Angular sincronizadas entre sí?

Estoy considerando usar una serie de eventos y escuchas de eventos para conectar un SPA con múltiples vistas concurrentes y anidadas, proporcionadas por Angular'senrutador ui. El diseño del SPA podría ser análogo a gmail, donde hay regiones de la pantalla separadas lógicamente (área izquierda con lista de carpetas de correo, barra de navegación superior, vista de detalles principales, etc.).

He estado buscando formas de mantener todos los controladores sincronizados con respecto a los modelos a los que todos deben acceder al mismo tiempo. Cuando la vista superior actualiza un modelo, si alguno de ellos se muestra en la vista principal, quiero que la vista principal note el cambio y actualice la vista en consecuencia.

Utilizo los servicios para compartir modelos entre los controladores, ya que se considera la mejor práctica, pero hay problemas con ese enfoque, tal como se analiza en profundidad.en esta pregunta.

Una posible solución a esto es usar Angular's.$broadcast y.$on('event, fn()) para que los controladores noten cuando un servicio que les importa tiene datos actualizados.

Problemas:

Usar eventos para pasar datos en lugar de usar servicios (acoplamiento apretado, ignorando cualquier fuente de datos autorizada). Te conozcopuede pasar objeto con eventos, pero no tienes que hacerlo.

Rendimiento (burbuja de eventos a lo largo de $ jerarquía de alcance, etc.).

$broadcast/$emit tengo problemas de rendimiento y acoplamiento estrecho que se cubren mucho aquí y en otros lugares, y estoy considerando usar la solución de una respuesta SOaquí para abordar las pérdidas de rendimiento / memoria de no limpiar los escuchas cuando se destruyen los controladores.

Mantenimiento (código spaghetti / ignorando OO y simplemente pasando el modelo de su aplicación completa en eventos). Esta es la pregunta principal que tengo para la comunidad: en base al siguiente diagrama (feo), imagino cada ángulo.service al disparar un evento cuando se actualizan los datos del modelo, y cualquier controlador que se preocupe por esos datos simplemente escucha el evento para disparar:

En realidad, es fácil de codificar (funciona ahora), pero me preocupa el dolor de cabeza de 5 años a partir de ahora de intentar hacer un seguimiento de todas las relaciones de eventos.

¿Alguien tiene alguna experiencia con un diseño como este, que me pueda aconsejar sobre un diseño más inteligente / conciso?

Gracias de antemano, y perdón por el diagrama en bruto ... espero que haya llegado al punto.

Respuestas a la pregunta(3)

Su respuesta a la pregunta