Modelo apropiado-Vista -

14

He estado leyendo acerca de Model View Controller, Model View Presenter, Model View ViewModel, etc., y en general, el concepto subyacente parece bastante simple de entender: mantener los elementos visuales bonitos y las tripas de la ciencia tan separados e ignorantes de entre sí como sea posible. No se consigue la lógica de la mantequilla de maní en el diseño chocolate; Genial, me gusta eso.

El problema es que todavía estoy un poco confuso en cuanto a esa tercera parte ... la que no es modelo ni vista. Todo el mundo parece tener su propia idea de cómo llamarlo, qué debería hacer, qué es correcto, qué es simplemente incorrecto ... y me estoy volviendo loco tratando de averiguar cuándo un Presentador se convierte en un ViewModel y cuando un View no debería No hagas eso porque ese es el trabajo del Presentador y ...

Estoy divagando.

En lugar de pedirle a alguien que explique la diferencia entre ellos, porque eso ya se ha hecho una y otra vez (lo sé; he leído más artículos de los que puedo contar). los pensamientos de algunos programadores sobre el modelo que me he improvisado yo mismo.

Dicho esto, ¿cómo clasificarías este diseño como, y quizás más importante, ves algo sobre esto que obviamente apesta? Claro, me encantaría Escuche que estoy haciendo bien si este es realmente un diseño sólido, pero preferiría que me dieran consejos sólidos sobre elogios.

Nota: ¿Usaré "the Bridge" para la tercera parte misteriosa de Model-View-? para evitar cualquier sugerencia subconsciente de lo que "debería" ser.

Modelo

  • Es la autoridad sobre los datos.
  • Recibe información sobre los cambios solicitados desde el puente.
  • Contiene y realiza toda la lógica de cómo los datos se relacionan con otros datos.
  • Informa al Puente cuando cambian los datos (para los datos en los que el Puente ha expresado interés). Edición de texto: permite a los suscriptores externos (sobre los que no sabe nada) monitorear sus resultados de estado o cálculo.
  • No tiene conocimiento de la vista.

Ver

  • Se preocupa por proporcionar al usuario una manera de ver y manipular los datos.
  • Recibe información sobre actualizaciones de datos desde el puente.
  • Contiene y realiza toda la lógica sobre cómo presentar los datos y los controles al usuario.
  • Informa al Puente cuando el usuario ha realizado una acción que (posiblemente) afecta al Modelo.
  • Informa al puente sobre qué información le interesa.
  • No tiene conocimiento del modelo.

Puente

  • Es el coordinador y el traductor entre el modelo y la vista.
  • Realiza los cambios de formato apropiados a la información que se pasa entre el Modelo y la Vista.
  • Retiene información sobre "quién necesita saber qué".
  • Tiene conocimiento tanto del modelo como de la vista.

Notas adicionales

  • En programas más complicados, es común que haya varios modelos. En esta situación, el Bridge generalmente asume la tarea de coordinar / traducir entre los múltiples Modelos, y por lo tanto se convierte en la autoridad en la cual se deben construir los modelos de protocall / API / design. (por ejemplo, si está creando un programa de juego de cartas y desea construir un modelo alternativo de baraja de mazo, debe usar el Bridge para determinar qué funciones se requieren para una comunicación adecuada con el Bridge).
  • En programas pequeños y simples con una sola Vista y Modelo, es común que el Puente "asuma" qué funcionalidad está disponible en cada lado. Sin embargo, a medida que los programas se vuelven más complejos, se recomienda que las Vistas y los Modelos informen su funcionalidad al Puente para que pueda evitar ineficiencias y suposiciones erróneas.

Creo que casi lo cubre. De todas formas, recibo con agrado cualquier pregunta que pueda tener sobre el diseño que tiendo a utilizar, y aliento igualmente cualquier sugerencia.

Y como siempre, gracias por su tiempo.

    
pregunta KoratDragonDen 30.10.2014 - 17:19

4 respuestas

7

Tu frase

  
    

"Es el coordinador y el traductor entre el modelo y la vista".

  

indica que su Bridge es el Presentador en una arquitectura MVP.

MVP y MVC son muy similares, excepto que en MVP solo el Presentador observa el Modelo, mientras que en MVC la Vista también puede observar directamente el Modelo (sin el Presentador como un "Puente").

Su responsabilidad como modelo

  
    

"Informa al Puente cuando cambian los datos (para los datos en los que el Puente ha expresado interés)"

  

quizás esté mal redactado o sea un error: no desea que el Modelo tenga una dependencia con el Bridge / Presenter / Controller o la Vista. En su lugar, utiliza un patrón de Observador, Eventos o Programación reactiva para permitir que el Puente se suscriba a los cambios en el Modelo. Y luego puede reformular su responsabilidad como:

  
    

"Permite a los suscriptores externos (sobre los que no sabe nada) controlar su estado o los resultados de los cálculos".

  

Si su modelo no tiene dependencias en su controlador o vista, es más fácil de probar y mucho más portátil.

    
respondido por el Larry OBrien 30.10.2014 - 20:56
5

Sospecho que una de las cosas que te confunde es que hay dos patrones completamente diferentes que comúnmente se denominan controlador de vista de modelo.

Está el original, tal como está implementado en smalltalk y es útil para los sistemas gui locales, y hay lo que tiendo a considerar como web-mvc, que intercambia algunas de las responsabilidades de las vistas y los controladores para que los controladores puedan sentarse el servidor con vistas en el cliente (quizás como html representado, o tal vez a través de ajax).

Su descripción me suena como si estuviera dentro de la mayoría de las definiciones de web-mvc.

    
respondido por el Jules 30.10.2014 - 17:51
2

Hay mucha discusión en la comunidad de programación sobre esta nomenclatura exacta. Nadie parece estar de acuerdo en mucho de nada.

Para mí, la forma en que el puente está conectado a la vista determina principalmente el nombre.

  • Si puede haber una colección de vistas por puente, entonces el puente es un controlador.
  • Si siempre hay una vista por puente, entonces el puente es un presentador.
  • Si puede haber una colección de puentes por vista, entonces el puente es un modelo de vista.

A veces las cosas no son tan claras. Por ejemplo, un presentador podría estar conectado a una vista compuesta hecha de subvistas múltiples o podría crearse un controlador sin ningún conocimiento de sus vistas. A pesar de esto, creo que mis reglas son un buen comienzo.

Como nota al margen, me gusta agrupar las responsabilidades de esta manera:

Modelo

Responsabilidad principal: datos persistentes
Funciones secundarias: validar actualizaciones, notificar a los observadores de actualizaciones

Ver

Responsabilidad principal: datos actuales
Roles secundarios: Aceptar entrada, presente UX

Puente

Responsabilidad principal: Actualizar datos
Funciones secundarias: limpiar entrada, sincronizar datos y vistas

    
respondido por el Jeffery Thomas 31.10.2014 - 04:14
0

Si bien su patrón sugerido parece correcto en la superficie y, sin duda, funcionará en casos pequeños, a medida que su aplicación se vuelve más compleja, enfrentará problemas en los que no está seguro de qué actualiza qué, quién escucha dónde y por qué. ¿Estoy intentando controlar tantos modelos desde tantas vistas, todos los que necesitan acceso entre sí, etc.?

Recomiendo extender tus ideas usando el siguiente patrón (tomado de la charla de Amy Palamountain Enemigo del Estado ):

Modelos

  • Estado de sincronización con el almacén de datos
  • Manejar la validación de datos nuevos / actualizados
  • Elevar eventos cuando cambian de estado

Views

  • Plantillas de render
  • Manejar eventos del modelo
  • Manejar eventos DOM
  • media la interacción entre el modelo y DOM

Controladores

  • Administra a lo sumo un par de Modelos & Vistas
  • Realiza un seguimiento de las vistas dentro de un contenedor

Módulos

  • La agrupación lógica de un controlador y sus vistas & Modelos
  • verificable
  • Pequeño y mantenible (responsabilidad única)
  • Coordina (a través del Controlador) el estado y los eventos de las Vistas & Modelos que contiene
  • Gratis para presentar sus propias vistas
  • No es libre de elegir donde para presentar sus Vistas

Administrador de diseño

  • Responsable de la composición del diseño
  • Define un shell de aplicación en el DOM con áreas en las que los módulos pueden presentar su contenido

Dispatcher

  • Escucha eventos (a través de la transmisión global de PubSub)
  • Responsable de cargar nuevos módulos basados en eventos
  • Entregue los módulos cargados al administrador de diseño
  • Administra toda la vida útil del módulo (creación, limpieza, almacenamiento en caché, etc.)
  • ejemplos de eventos:
    • Cambios de ruta (incluida la ruta de carga inicial)
    • Interacción del usuario
    • Evento de módulo generado a partir de un evento modelo debido a un cambio de estado del lado del servidor, etc.

Aplicación

  • Responsable de la configuración general, crea instancias de cosas como:
    • Despachador
    • Enrutador
    • transmisión PubSub
    • madereros
    • etc

Este tipo de patrón permite que su aplicación pueda componerse, probarse por unidad, elimina la complejidad que un puente acumularía con el tiempo, mantiene las preocupaciones bien separadas, etc.

Como señala Amy: tenga cuidado de no construir un servidor en el cliente. Y tenga cuidado de no caer en la doctrina de "estoy haciendo un framework MV *, por lo tanto debo

respondido por el Jess Telford 07.11.2014 - 00:32

Lea otras preguntas en las etiquetas