Comunicación intercontrolador en MVC/MVP

Question

¿Cuál es un buen método para la comunicación entre controladores sin acoplamiento en MVC/MVP?

Por ejemplo, en una Cita, el usuario debe crear y agregar un nuevo contacto, o agregar uno existente.

Eligen crear un nuevo contacto. Cuando se completa, el contacto se agrega a la cita, y la IU devuelve al usuario a esa cita. Si presionan cancelar, se devuelven a la cita.

Quiero volver a utilizar el contacto en otro lugar, por lo tanto, no debería saber nada acerca de Cita. Por ejemplo, si creo un contacto de la lista de contactos, debería regresar allí cuando haya terminado.

Estas son algunas de las opciones que he pensado:

• acción ContactsController llama ApplicationController.getNextStep (este) y el ApplicationController se lo imagina el siguiente paso en nombre de la ContactsController

• ContactsController plantea el evento "acción completa" o similar, y el ApplicationController está escuchando este evento y llama al siguiente paso correcto

• QuoteController pasa en un "bastón" a ContactsController con el siguiente paso, que ContactsController llama al finalizar

• ContactsController provoca el evento "actioncomplete" o similar, y QuotesController está a la escucha de este evento y llama al siguiente paso correcto.

¿Tiene experiencia con estos? ¿Otras ideas? ¿Cuál causará el menor dolor de cabeza en una gran aplicación?

Gracias!

Answer 1

Supongo que responderé a mi propia pregunta. Con suerte, obtengo esa dulce y dulce recompensa.

Piense en esto desde la perspectiva de enviar a su empleado consultor a un cliente. Él sabe cómo hacer su trabajo, pero no sabe qué hacer cuando termine. Quieres que sea flexible sobre lo que hace a continuación.

A veces su jefe lo envía. Algunas veces el CEO lo hace (puede que él no sepa a dónde enviarlo después). A veces el cliente lo llama con una emergencia (definitivamente no sabe a dónde enviarlo después). A veces simplemente agarra una nueva tarea de la pizarra.

No podía hacer una de varias cosas:

• que podría decirle a llamar a la oficina central al que ha hecho, y la oficina central dará cuenta de ello para él. no necesita saber de ninguna otra persona, solo el número de teléfono de la oficina central.

• podría decirle qué hacer cuando termine, antes de irse. si se ha ido por un tiempo, su siguiente tarea podría haber cambiado mientras tanto.

• podrías decirle que publique en Facebook cuando haya terminado, la oficina central lo estará buscando, y le dirá qué hacer. la oficina central debería estar pendiente de muchas publicaciones de Facebook de todos sus consultores.

• puede decirle a su supervisor que responda su llamada cuando haya terminado, pero luego su supervisor debe estar en la oficina, y tal vez cambie de supervisor.

Personalmente, me gustaría pasar en una función de devolución de llamada. Si esa devolución de llamada es nula, el destinatario debería preguntarle a la aplicación qué hacer. Eso le da cierta flexibilidad, al tiempo que permite un proceso principal para administrar las cosas y no depende de una función importante en la aplicación.

Esto sería equivalente a dar al consultor el número del próximo cliente al que llamar, cuando haya terminado. Si no obtiene un número, llama a la oficina central.

También podría usar un evento, y no es una mala idea. El único problema podría ser si varios objetos están escuchando este evento, podría ocurrir algo desafortunado.

Answer 2

Puede implementar algún tipo de pila de navegación, donde primero se insertan los Controladores de Cita o Contactos, y luego empujan el Controlador de Contacto cuando sea necesario. Cuando el controlador de contactos está listo, se abre y llega al siguiente para saber a dónde ir. De esta forma, está completamente desacoplado y puede reutilizarse en cualquier lugar, y puede anidarse en n niveles profundos.

Answer 3

Si entiendo su pregunta correctamente, tiene una acción cuidadosamente encapsulada por un controlador y desea asegurarse de que su comportamiento posterior a la ejecución se pueda definir de la manera más dinámica posible.

Su idea de una función de devolución de llamada es muy buena, pero iría un paso más allá y la convertiría en Func <>, lo que le permite utilizar cierres. Ampliaré la metáfora de su consultor: en lugar de pasar un número de teléfono a su representante, en su lugar, pídale que se vuelva a conectar a la oficina y reciba instrucciones de allí. La belleza del uso de cierres es que puede acceder al contexto de llamadas directamente desde el código que de otro modo estaría fuera del alcance; en otras palabras, el cierre puede acceder al todos de las variables y funciones en el controlador de host.

Cuando el vendedor se hace con su tarea, simplemente abre el maletín (Func <>) y mete la mano en su escritorio en la oficina para ver si alguien ha puesto un elemento de las tareas en el cajón de su oficina.

Jon Skeet (también en StackOverflow) tiene un gran recurso aquí: http://csharpindepth.com/articles/chapter5/closures.aspx