MVP y granularidad de presentador

Question

Hemos estado utilizando el patrón de MVP y las formas de pago con bastante éxito. Sin embargo, siempre surge una pregunta acerca de MVP:

¿Qué es buena granularidad para presentadores?

Lo que quiero decir con esto es: Con Winforms, una granularidad fina generalmente funciona bastante bien para los controles del usuario. De esta forma, es fácil reutilizar los controles del usuario y usarlos como componentes básicos mientras se diseñan GUI más complejas. Sin embargo, tener la misma (gran) granularidad con los presentadores parece ser un problema.

Por un lado, tener presentadores de grano grueso obstaculiza la capacidad de utilizar "plug-in" controles y tipo de violar el principio DRY: Múltiples presentadores a menudo tienen que aplicar la misma lógica (rellenar una lista de clientes , por ejemplo), que es usado por controles múltiples, 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 guardar al cliente de inmediato; a veces necesita vincularlo a otra cosa; a veces solo es necesario 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, se puede lograr 1-presenter-1-view. Lo que se considera cambios de "1 vista".

¿Cuál es usualmente considerada como una de las mejores prácticas para la granularidad del presentador usando MVP y Winforms?

• presentadores de grano fino y personalizable comportamiento 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: Principalmente utilizamos Supervising Controller pero creo que también se aplica a la vista pasiva. Perdón por la larga pregunta, también.

Answer 1

Utilizamos MVP en todos nuestros clientes y esta es definitivamente una conversación que aparece en más de una ocasión. ¿Cuán limpio debe ser nuestro código detrás de las clases y presentadores? Habiendo dicho eso, hemos elegido usar el enfoque del 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 un DB para completar un cuadro combinado, por ejemplo) se encuentran en una clase de servicio público. Cualquier validación de datos ingresados ​​por el usuario se ubica en una clase BO que puede ser reutilizada por cualquiera y/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 visualización que usa el presentador.

Si quiero mostrar una lista de clientes, se la paso a la vista que tiene una DisplayCustomerList y usa la combinación de controles de usuario que necesita 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 muchos tipos diferentes de máquinas de corte de metales. Así que ponemos mucho énfasis en poder arrancar la interfaz de usuario y reemplazarla con una interfaz de usuario completamente diferente (correspondiente a una máquina diferente). Todas estas interfaces de usuario hacen referencia al mismo conjunto de conjuntos de núcleos.

La jerarquía se parece a esta implementación Asamblea

Ver EXE Presentador Comando - comandos se ejecutan por el presentador que modificar el modelo presentador Interfaces Asambleas Modelo

A un lado están ensamblados cargables que definir contenido dinámico como qué tipos de archivos se pueden cargar, informes, controladores de dispositivos de corte, etc. Implementan diversas interfaces que se encuentran en los ensamblajes modelo

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

La pregunta esencial que hago al usar MVP es "¿Qué sucede si quiero reemplazar por completo los formularios con otra cosa?". Las respuestas a esa pregunta identificarán dónde dependes demasiado de un control de usuario o un motor de formulario en particular.

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