java - mvc - Aplicando el patrón MVP a JDialogs

mvp android studio

Question

Estoy escribiendo una aplicación Swing, y además de mi pregunta anterior , me he decidido a utilizar el patrón Model-View-Presenter para separar la interfaz de usuario de la lógica comercial.

Cuando se inicia mi aplicación, ejecuta el siguiente código:

Model model = new BasicModel();
Presenter presenter = new Presenter(model);
View view = new SwingView(presenter);
presenter.setView(view);

presenter.init();

que crea la interfaz de usuario. Los eventos son generados por la View y delegados en el Presenter . El Presenter luego manipula el Model y actualiza la View consecuencia.

Para manejar algunos eventos, necesito obtener más información del usuario. En el caso de estos eventos, creo que es apropiado que la vista de Swing JDialog una nueva ventana de JDialog .

Una línea de pensamiento me hace sentir que este podría ser el código apropiado en el Presenter :

public void handlePreferences() {
    Preferences prefs = view.getPreferences();
    model.setPreferences(prefs);
}

Es decir, el contenido de cada JDialog debe representar un objeto distinto que debe recuperarse de la View y actualizarse en el Model . Sin embargo, esto deja la pregunta: ¿creo un nuevo Model para representar el objeto de Preferences y un nuevo Presenter para el manejo de eventos en ese JDialog ?

Me parece que la creación de un nuevo Presenter y Model interno a la View original me obliga a hacer un montón de trabajo que sería más difícil de portar si quisiera cambiar la interfaz de usuario para usar JSF, por ejemplo.

Por favor, siéntase libre de agregar comentarios para aclaración.

Answer 1

Mi consejo sería pensar cuáles son estas "preferencias" fundamentalmente. ¿Son parte de la lógica empresarial subyacente? Si es así, deberían formar parte de la estructura del modelo. ¿Están especificando la forma preferida por el usuario de interactuar con los datos comerciales? Entonces deberían ser parte de la vista. Eso puede parecer teórico, pero en mi experiencia ahorra muchos dolores de cabeza al final.

Si no puede resolver eso, entonces donde se guardan las preferencias le da otra pista. si necesitan guardarse con los datos manipulados, entonces probablemente sean parte de la lógica comercial. Si se guardan en el archivo de preferencias personales del usuario, entonces no son, y deberían considerarse vistas.

Answer 2

No, no necesitas otro "modelo" solo para las Preferencias

Simplemente pase el presentador y el modo como argumentos en el constructor de JDialog. Es más fácil programar una gran aplicación Swing cuando hay

• 1 modelo
• 1 controlador (que puede contener los más pequeños)
• vistas múltiples (pero en las MISMAS clases de datos / modelo)

Tenga en cuenta que 1 modelo! = 1 clase. El "modelo" de una aplicación Swing puede ser realmente un "árbol" de clases "modelo" separadas que tienen una "raíz" común.

Entonces en tu caso necesitas

Modelo "Global" -> (contiene) modelo de "Preferencias".

Answer 3

Aunque no es raro tener patrones de diseño "anidados", no es necesario en su caso. Basándose en las otras respuestas:

Modelo
- Contiene todos los datos reales, variables, objetos
- sabe cómo establecer sus valores de datos almacenados a los nuevos valores
- responde a las órdenes (llamadas de método)
- tiene el método setPreferences (value1, value2, value3 ...);

Ver
- es el IO de la aplicación, solo salida y entrada
- solo puede funcionar en sí mismo, en su estado
- mantiene variables locales y objetos, ej. tiene JButtons, JMenus, int contadores ...
- sabe cómo informar al presentador del cambio de estado
- su estado es visible para el presentador, o revelado por la llamada al método
- responde a las órdenes (llamadas de método)
- sabe cómo obtener las preferencias del usuario
- tiene el método askForPrefs ();
- tiene el método getPrefState ();

Presentador
- Responde a los cambios de estado
- Toma toda la decisión, le dice a los otros objetos qué hacer (no cómo hacerlo)
- sabe cuando se necesitan preferencias
- sabe dónde obtener nuevas preferencias y dónde colocarlas
- tiene el método newPrefsAvailable ();

... para obtener más información del usuario. En el caso de estos eventos, creo que es apropiado que la vista de Swing genere una nueva ventana de JDialog.

Presentador: verifica el Modelo, determina que se requieren nuevas preferencias
Presentador - this.myView.askForPrefs (); // le dice a la vista que le pida al usuario los valores de pref
View.askForPrefs: muestra un cuadro de JDialog, retVals almacenados en la vista como un cambio de estado
Ver - this.myPresenter.newPrefsAvailable ();
Presentador: responde con this.myModel.setPreferences (this.myView.getPrefState ());
Model.setPreferences - cambia los valores almacenados a View.getPrefState ()
Presentador - verifica el Modelo - determina que las preferencias son buenas
Presentador: continúa

El JDialog se trata simplemente como una extensión de la Vista, es un miembro de la Vista como lo sería un JButton. El modelo tiene los valores de preferencia reales autorizados y la vista tiene variables locales que representan el estado del JDialog.