Comunicación de componentes cruzados dentro de una vista (MVC)

Question

¿Cuáles son algunas de las mejores prácticas para orquestar la interacción entre los componentes complejos que se encuentran en su vista?

No estoy hablando de widgets simples como un cuadro combinado o un control de la cuadrícula, pero los componentes que se componen de múltiples widgets y que pueden merecer que se prueben por sí solos.

¿Quieres que:

1. Definir interfaces abstractas para cada componente, dejar que el controlador conectarlos a través de la inyección de dependencia a dejarlos hablar directamente entre sí a través de llamadas a métodos? Por lo tanto, los componentes conocen las interfaces de otros componentes.
2. Defina los eventos que cada componente puede disparar y deje que el controlador los conecte directamente a través de los detectores de eventos el uno al otro? Por lo tanto, los componentes tienen controladores de eventos conectados a los receptores de eventos de otros componentes.
3. Defina las interfaces abstractas para cada componente, defina los eventos que pueden disparar y deje que el controlador escuche todos los eventos y realice llamadas a los métodos en las interfaces. Por lo tanto, los componentes son completamente independientes de otros componentes.
4. ¿Una aplicación clásica del patrón Observer?
5. ¿Algo más?

Actualización: he derrame cerebral a cabo "dejar que el controlador ..." de # 1-3, porque no es necesariamente el controlador que tiene que hacer el enrutamiento/orquestación en esos casos. Podría ser la Vista en sí misma.

He adoptado el método n. ° 3 en un proyecto reciente y estoy contento con el desacoplamiento y la capacidad de prueba individual de los componentes. Sin embargo, tengo la sensación de que podría simplificar el cableado de los componentes. En mi caso, el objeto View principal tiene que agregar múltiples detectores de eventos en cada componente y luego llamar a los métodos sobre los componentes apropiados, después de algunas veces hacer algún procesamiento local (como hablar con el Modelo). El código para agregar los controladores de eventos parece un poco desordenado y particularmente estoy buscando una manera limpia de hacerlo.

Answer 1

La opción n. ° 3 suena como el patrón Mediator y suele ser el mejor enfoque cuando la lógica de actualización y la comunicación entre los objetos es compleja. También tiene la ventaja adicional de mantener la lógica de control y la inicialización centralizadas, lo que hace que el seguimiento y la depuración de este tipo de casos sean más fáciles.

Answer 2

Parece que tienes el conocimiento para responder a tu propia pregunta sobre esto, pero tal vez solo te falta la confianza para sumergirte. ¿Estás explorando o estás atrapado en algún lugar?

Yo agregaría que una cosa más que puede hacer es colocar un administrador de componentes entre todos los objetos para facilitar la comunicación. En el pasado, cuando hacía algo similar, el objeto de administración terminaba tomando datos de cada componente, fusionando los datos entre sí y pasándolos al modelo como una gran solicitud. Cada uno de mis componentes tenía un delegado al que llamarían y en el cual se pasarían los datos y, por supuesto, la implementación de ese delegado estaba en mi administrador de componentes.

También dejé que el objeto administrador actuara como un proxy para la red. Estaba esperando que la complejidad aumentara antes de adherirme a SRP y convertir esa responsabilidad en su propia clase.

Básicamente todo lo que dices suena bien. Yo recomendaría simplemente bucear y explorar.