MVP y granularidad del presentador

Question

Hemos estado usando el patrón MVP y Winforms con bastante éxito. Sin embargo, siempre surge una pregunta sobre MVP:

¿Qué es una granularidad buena para los presentadores?

Lo que quiero decir con eso es: con Winforms, una granularidad fina generalmente funciona bastante bien para los controles del usuario. De esa forma, es fácil reutilizar los controles de usuario y usarlos como bloques de construcción mientras se diseñan interfaces gráficas de usuario más complejas. Sin embargo, tener la misma granularidad (fina) con los presentadores parece ser un problema.

Por un lado, tener presentadores de grano grueso dificulta la capacidad de usar el complemento "" controles y viola el principio DRY: los presentadores múltiples a menudo necesitan implementar la misma lógica (llenar una lista de clientes, por ejemplo), que es utilizada por controles múltiples y más complejos.

Por otro lado, los presentadores de grano fino parecen limitar la capacidad de reutilizar los controles en diferentes situaciones. Por ejemplo, una vista de edición a veces puede necesitar salvar al cliente de inmediato; a veces necesita vincularlo a otra cosa; a veces solo necesita validarlo; y así. A menudo depende del control más complejo. Pero también hay una buena cantidad de comportamiento compartido.

Tenga en cuenta que, en ambos casos, 1-presentador-1-vista es alcanzable. Lo que se considera " 1-view " cambios.

¿Qué se suele considerar las mejores prácticas para la granularidad del presentador con MVP y Winforms?

¿Presentadores
• finos y comportamiento personalizable a través de opciones o algo por el estilo?
• ¿Presentadores de grano grueso y baja reutilización del presentador?
• ¿Algo más?

Descargo de responsabilidad: utilizamos principalmente el controlador de supervisión, pero creo que también se aplica a la vista pasiva. Lo siento por la larga pregunta, también.

Answer 1

Utilizamos MVP en todos nuestros clientes y esta es definitivamente una conversación que surge en más de una ocasión. ¿Qué tan limpio debe ser nuestro código detrás de las clases y los presentadores? Dicho esto, hemos optado por utilizar el enfoque de presentador de grano grueso. Básicamente, cada formulario tendría su propio presentador y solo obtendría y establecería propiedades de cualquiera de los controles en un formulario particular usando su vista. Los controles de relleno (una llamada a una base de datos para llenar un cuadro combinado, por ejemplo) se encuentran en una clase de servicio público. Cualquier validación de los datos ingresados ??por el usuario se encuentra en una clase BO que puede ser reutilizada por cualquiera o todos los presentadores. Espero que esto ayude.

Answer 2

En mi sistema CAD-CAM mis presentadores no usan controles de usuario. Los controles de usuario residen en la vista que reside en un ensamblado EXE que implementa las interfaces de vista que usa el presentador.

Si desea mostrar una lista de clientes, la entrego a la vista que tiene DisplayCustomerList y utiliza cualquier combinación de controles de usuario que necesite para mostrar la lista de clientes. Si varias vistas muestran la lista de clientes de la misma manera, en el ensamblaje ExE / View comparten un control de usuario o una clase para hacerlo. Esa clase no sale de esa asamblea.

Nuestro software está adaptado para ejecutar diferentes tipos de máquinas de corte de metales. Por lo tanto, ponemos mucho énfasis en poder extraer la IU y reemplazarla con una IU completamente diferente (correspondiente a una máquina diferente). Todas estas IU hacen referencia al mismo conjunto de conjuntos principales.

La jerarquía se ve así

Ver EXE Implementación del presentador Conjunto de comandos: el presentador ejecuta los comandos que modifican el modelo Interfaces de presentador Ensamblajes de modelo

A un lado están los ensamblajes cargables que definen contenido dinámico como qué tipos de archivos se pueden cargar, informes, controladores de dispositivos de corte, etc. Éstos implementan varias interfaces que se encuentran en los ensamblajes de modelos

Una cosa que hago es no impulsar un presentador de vista para cada diálogo. Si el cuadro de diálogo está estrechamente vinculado con un comando, se define, crea y utiliza junto con la clase de comando. Ocasionalmente, un grupo de comandos relacionados compartirá un diálogo (manejo de archivos, por ejemplo).

La pregunta esencial que hago cuando uso MVP es "¿Qué sucede si quiero reemplazar completamente los formularios con algo más?". Las respuestas a esa pregunta identificarán dónde depende demasiado de un control de usuario en particular o de un motor de formularios.

El mayor problema (y para el que no tengo una buena respuesta) de mi configuración es que los IDE y los idiomas actuales hacen que sea muy fácil vincular los controles de los usuarios con los registros de la base de datos. Es tan productivo en comparación con cualquier otra configuración que tiende a dominar el diseño. No he tenido que lidiar con el problema mucho en mi aplicación CAD-CAM, así que no tengo otra respuesta que pasar el conjunto de datos a la vista y dejar que lo maneje. Este sitio tiene algunos patrones que pueden ser útiles en esta situación.