MVP y controles de usuario múltiples

Question

Estoy tratando de usar el patrón MVP y me encuentro con un problema de diseño. Estoy desarrollando una aplicación que tendrá varios UserControls. Los UserControls en sí mismos no tienen nada que ver entre sí y solo representan un subconjunto del modelo real. Según lo que he leído, las personas tienden a decir que debes usar un presentador por vista. Esto parece tener sentido, pero si tengo 30 UserControls, ¿realmente quiero 30 Presenters? Por otro lado, si tengo 1 Presentador y 1 Vista que representan toda la vista de "aplicación", entonces tendré interfaces de Vista y Presentador hinchadas. Entonces, cada Vista debería implementar métodos que no tienen nada que ver con eso. Mi pregunta es, ¿existe una mejor manera de manejar múltiples UserControls, o debería simplemente crear 1 Presenter para cada View?

Answer 1

Tendría más sentido agrupar el código que está relacionado en un objeto. Entonces, en este caso, si las vistas son agrupaciones específicas de código relacionado, entonces el presentador también imitaría estas agrupaciones. Tener un presentador "global" para diferentes vistas agruparía el código no relacionado en un objeto. Definitivamente hincharía la interfaz para el presentador también. Consulte el single responsibility principle.

Ahora, podría tener una clase Presenter Manager que podría darle acceso a cada interfaz del presentador, estados like the Interface Segregation Principle, ya sea por herencia (tenga un presentador concreto global que implemente muchas interfaces de presentador ... que viola la responsabilidad única)) o agregación (tener presentadores individuales para cada interfaz y obtener funciones ... por lo tanto, la interfaz global sería la de obtener funciones) o una combinación de ambos (el presentador global es algo así como un adaptador).

Creo que la mejor solución sería simplemente tener 30 presentadores diferentes.

Answer 2

Cada vista no tiene que implementar la misma interfaz ... ¿Por qué no definir las interfaces para cada control y tener un presentador para toda la pantalla que contiene todos los controles? El presentador puede "conectar" los eventos en cada vista de acuerdo con los eventos definidos por la interfaz que requiere cada vista, con los controladores de eventos apropiados en el presentador (y en un controlador si está haciendo MVPC). También puede ser necesario otra interfaz para representar la funcionalidad Presentador de que todos Ver necesitan tener acceso a en común ...

• Si estás haciendo MVPC continuación, ver los eventos que afectan al modelo wopuld ser "manejado" en el controlador, mientras que los eventos de Vista que solo afectan a otras partes de la Vista se manejarán en el Presentador.

Answer 3

Usted debe hacer un presentador por un control debido a:

• que le permiten tener pruebas unitarias enfocadas que abordan solamente que el control
• una mayor capacidad de mantenimiento debido al hecho de que usted ganó no es necesario admitir gigantesco presentador que contenga la unión de lógica de presentación de todos los controles
• que evitarían la redundancia en casos de tener el mismo control en varias páginas
• Aumenta SRP por tener controles centrándose en su lógica específica, mientras que la página realiza contenedores funciones específicas:

Hay dos problemas generalmente mencionados en relación con la decisión “presentador por el control”:

• El contexto compartido es un problema donde debido a que todos los controles muestran solo piezas del mismo contexto de datos de página, esa situación puede parecer un caso de uso problemático que conduce a muchos del código redundante de recuperación de datos en cada uno de los controles. Esto se puede solucionar fácilmente a través de la inyección de dependencia donde la página (o controlador) realiza la recuperación de datos individuales y luego inyecta el objeto de contexto de datos en cada uno de los presentadores \ vistas (generalmente implementando alguna interfaz que lo habilite). En caso de patrón MV-VM (Silverlight, WPF) mismo efecto se puede lograr a través de datos que limitan donde la página fijaría su DataContext que luego se utiliza de vistas en sí
• La comunicación entre vistas en la misma página es segundo problema que se puede resolver fácilmente utilizando dos enfoques:
• Los controles están publicando eventos a los cuales la página se suscribe y luego realiza llamadas directas a métodos apropiados en otros controles (la página es contenedor de todos los controles, lo que significa que conoce todos sus miembros)
• Observer patrón de diseño
• agregador Evento patrón

En cada uno de esto se acerca controles se comunican entre sí sin ser consciente de sí

Answer 4

vieja pregunta, pero voy a la tubería y que no está de acuerdo con las otras respuestas: no desea un presentador por UserControl, más de lo que desea una prueba de unidad en cada UserControl - eso sería un mal uso ciego de un patrón de diseño.

Un UserControl no es una Vista.

Cada área lógica de su aplicación debe tener un presentador; cómo se divide cada uno - cuántos controles, qué muestra qué - es solo una preocupación de composición.