Mi presentador debe solicitar al usuario más información. ¿Cómo lo conecto?

Question

Estoy trabajando con el patrón de Vista pasiva. El usuario hace clic en el botón de una nueva cuenta. La vista delega responsabilidad al presentador mediante llamadas a métodos sin parámetros.

El problema es que hay varios tipos de cuenta, por lo que el usuario debe elegir cuál quiere crear. ¿Cómo resuelvo esto?

1. Cree un nuevo formulario desde la vista, obtenga la información necesaria y exponga como una propiedad para que el presentador pueda recuperarla. (Esto ignora la noción de que la vista no debería tener ninguna lógica)
2. Cree y use el nuevo formulario del presentador. (Esto vincula al presentador directamente a un formulario, ignorando todo el punto de MVP)
3. Cree el nuevo formulario en otro lugar y páselo como argumento de constructor al presentador ... o la vista.
4. Olvídalo y agrega un nuevo botón para cada tipo de cuenta. (Hay varios tipos de cuenta y esto saturará la interfaz de usuario, pero que así sea).
5. Voy por esto de la manera incorrecta y necesito repensar mi diseño. (Si este es el caso, se apreciaría un empujón en la dirección correcta).

Answer 1

Mi solución para esto fue diferente de lo que esperaba. Cambié el botón que el usuario hizo clic en un DropDownMenuButton. Luego pasé una lista de cadenas de tipos de cuenta a la vista que llena el menú desplegable. También creé un controlador de eventos para el evento de clic del elemento del menú desplegable, que actualiza una propiedad pública con el nombre del elemento del menú y luego delega todo lo demás al presentador.

El presentador solo tiene que obtener el nombre del elemento del menú de la propiedad expuesta y luego buscar el tipo de cuenta en un diccionario privado de tipos de cuenta utilizando el nombre del tipo de cuenta como clave.

Answer 2

Probablemente crearía otro par de presentador-vista para obtener el tipo de cuenta. Entonces cualquiera

• su presentador llama al otro presentador directamente para mostrar el nuevo formulario o
• su presentador le pregunta a su modelo el tipo de cuenta correcto. El modelo sabe que debe preguntar en otro lugar e invoca & Quot; presentador de tipo de cuenta & Quot; o incluso el " modelo de tipo de cuenta " ;.

Creo que elegiría la primera opción a menos que su presentador se vuelva difícil de manejar.

Answer 3

No soy un experto en MVP pero manejaría esto usando un delegado para obtener el tipo de cuenta de la vista. El presentador invoca al delegado en la vista que abre & Quot; seleccione el tipo de cuenta & Quot; formulario y devuelve el tipo de cuenta seleccionado cuando el usuario ha seleccionado un tipo de cuenta y cierra el formulario.

Answer 4

Si está hablando de una interfaz simple para seleccionar un tipo de cuenta, la OMI depende de la cantidad de tipos de cuenta. Simplemente agregaría nuevos botones para cada cuenta. Sin embargo, si tiene muchos tipos de cuenta, tendría un cuadro combinado con la lista de todas las cuentas posibles y la primera (la que el usuario ve primero) será un tipo no válido o no seleccionado. También agregaría alguna etiqueta que diga & Quot; Seleccione el tipo de cuenta para crear & Quot ;, luego presione un solo botón que envía el valor en el cuadro combinado al modelo. De esta manera, si el usuario simplemente hace clic en el botón sin seleccionar un tipo de cuenta, el modelo validará el tipo y devolverá el problema a la vista (y la vista puede resaltar el cuadro o el texto en rojo o lo que sea). Eso evitaría que el usuario pierda la selección del tipo de cuenta. Este enfoque también facilitaría las pruebas unitarias.

Si está hablando de que cada tipo de cuenta tiene información diferente que debe completarse, entonces tendría que tener una vista y un presentador diferentes para cada cuenta. (Esto sería lo que necesita después de que el usuario seleccione el tipo de cuenta)