Según tengo entendido, cuando usamos MVP movemos toda la lógica de presentación al presentador. Pero no queremos que el presentador conozca la implementación de la vista, entonces, ¿cómo podemos navegar a otra pantalla en la aplicación? ¿Cómo gestionas el flujo de aplicaciones en tu aplicación real?¿Cómo se navega entre vistas en MVP usando C# WinForms?
Es un método en la vista. Por lo tanto, tendría un método abstracto, como ShowCustomerForm(), por ejemplo, y la implementación de WinForms sería CustomerForm.Show (o lo que sea en WinForms) y en WebForms sería Response.Redirict (CustomerForm.aspx).
El uso de algunos interfaz de navegador, por ejemplo:
interface INavigator
{
void MoveTo (string screenName);
void MoveTo (string screenName, NavigationParameters parameters);
}
Cada presentador tendría entonces una instancia de este navegador pasado en el constructor. De esta forma, la navegación se desacopla del presentador y de las vistas individuales.
Puede hacer que la asignación entre los nombres de pantalla y las clases de formulario reales se definan en una configuración.
Supongo que se refiere a otra pantalla que tiene su propio par MVP?
Estaba pensando en ese caso esta mañana, mi solución probablemente será que haya un coordinador que conozca el presentador y el par MVP que debe abrirse. Ese abre el nuevo presentador + vista y, cuando termina, opcionalmente llama a un método en el primer presentador con los resultados.
De esta forma, el primer MVP no tiene que saber nada sobre la nueva pantalla, solo activa un evento. La lógica para abrir la segunda ventana y comunicarse nuevamente está completamente contenida en el Coordinador.
Hacemos esto usando lo que Lennaert llama coordinador (lo llamamos un controlador de flujo de trabajo). Vengo del desarrollo web de Java y la idea era una forma de ApplicactionController. Me he encontrado con algunos problemas con esto, el controlador de flujo de trabajo ejecuta un comando. Cada comando representa un flujo de trabajo o una serie de pasos relacionados (por lo tanto, el nombre workflowcontroller). El controlador de flujo maneja la navegación entre los comandos y un controlador de flujo tiene un navegador que navega entre los pasos. Cada paso tiene un evento de finalización (al que se conecta el presentador) y el Método NextStep que usamos para navegar al siguiente paso. Nuestro worflowcontroller está estrechamente acoplado al menú para que podamos navegar entre diferentes flujos de trabajo. Los pasos establecen el vínculo entre la vista y los presentadores. No tenemos ninguna configuración y hemos cableado la lógica que establece el próximo paso para ejecutar en un método llamado NextStep. Está en producción, pero no estoy muy satisfecho con esto. Demasiados detalles para entrar aquí. He pensado en cambiar a algo más orientado al evento. Usamos un bus de mensajes para hacer todas nuestras otras comunicaciones y me gustaría cambiar a usar esto para navegar entre pantallas. No sé si eso sería útil o no. nuestras pantallas en su mayoría consisten en flujos de trabajo secuenciales.
Y después de que la vista haya creado una instancia de la interfaz ICustomerForm, puede pasarle un presentador usando algún método como este: Init (CustomerFormPresenter) – dzendras