¿En MVC debería un modelo contener modelos de subvista?

8

Algunos antecedentes:

Un colega y yo mismo tenemos diferentes interpretaciones de MVC, lo que significa que, dado el mismo problema, se nos ocurren soluciones radicalmente diferentes. Él proviene de un fondo de Java donde cada componente de MVC puede modelar tradicionalmente un objeto y yo provengo de un fondo de Haskell y tengo poca o ninguna experiencia con OOP.

El espacio del problema:

El problema que intentamos modelar actúa un poco como un entorno de escritorio. Tenemos una noción de la sesión de los usuarios (tal vez su inicio de sesión, su fondo de escritorio) y los procesos en su escritorio (por ejemplo, iTunes, Finder, etc.) que tienen sus propias propiedades de modelo (minimizadas, etc.).

Estamos de acuerdo con el siguiente punto: creemos que HMVC es la mejor representación. Estamos de acuerdo en que tenemos dos objetos MVC, Session (escritorio) y Process (aplicación) y que no queremos que Process tenga una noción de Session o un vínculo de retroceso.

Una vez que estamos en desacuerdo, sin embargo, es el significado principal de MVC y cómo eso afecta a donde mantenemos la lista de procesos en el escritorio de los usuarios .

Su interpretación:

Argumenta un punto muy válido que tradicionalmente es fácil de modelar en código y en nuestro sistema de renderizado. Él dice que la lista de procesos debe ser una lista de objetos ProcessController dentro de SessionController que a su vez tienen sus modelos como objetos separados dentro de ellos. Esto significa que hay una cantidad significativa de estado dentro de SessionController y SessionModel que es relevante para lo que SessionView necesita representar.

Esto parece estar muy en armonía con lo que pudimos leer en Internet en una breve búsqueda.

Mi interpretación:

Mi interpretación requiere el cambio arquitectónico más grande y parece más difícil de implementar en el código, pero creo que es más correcto conceptualmente. Me gustaría que alguien explique por qué este no es el caso, o que presente un modelo diferente (si no es MVC) que se alinee con esta interpretación y resalte algunas fortalezas y debilidades de ambos patrones para que podamos tomar la decisión más informada (ninguno de nosotros tiene una sólida formación en arquitectura de software).

Veo MVC como una tríada con tres componentes intercambiables: el Model , el Controller y el View . Esto concuerda con lo que soy capaz de leer en Internet, y algunas fuentes dirán cosas como "puntos de vista, controladores y modelos con la misma interfaz deben ser intercambiables a efectos diferentes". La forma en que me imagino que esto funcione es la siguiente:

  • Cuando intercambias el modelo, estás cambiando la forma en que se validan o almacenan los datos de
  • Cuando intercambias el controlador, estás cambiando el comportamiento de la página , pero no todo lo que pueda alterar el contenido de datos conceptuales de la página
  • Cuando intercambias la vista, estás cambiando la forma en que se muestra la página

A partir de esto, razoné que dado cualquier Model y View , intercambiar solo el controlador no debería cambiar los datos que la página muestra inicialmente porque el controlador debería cambiar solo el comportamiento y no el "contenido" de la página. Creo que esto se alinea con la visualización conceptual del controlador como un 'controlador de estación' en un sistema ferroviario, un plano del ferrocarril como modelo y la manifestación física real y el aspecto de las pistas (en diferentes versiones, por ejemplo ' Real 'o' Virtual 3D ') como la vista.

Aquí es donde no estamos de acuerdo:

Argumento que debido a que los diferentes procesos en el escritorio cambian los datos que se mostrarán al usuario en el SessionView (modelo I los procesos como datos relevantes ), el SessionModel debería contener la lista de instancias de ProcessModel . Esto significa que el uso de cualquier SessionController aleatorio con el mismo SessionView debería mostrar conceptualmente los mismos datos (procesos en el escritorio).

Argumenta que tiene más sentido que un Model nunca sepa sobre otro modelo. Esto significa que el SessionController tendría una lista de ProcessController s dentro de él y cada objeto Controller tiene un enlace a su modelo. Dado un SessionView y el mismo SessionModel pero un SessionController diferente, los datos que se muestran al usuario deben ser radicalmente diferentes.

Por favor, defiende / contradice cada interpretación y ayúdanos a alcanzar el resultado más informado.

¡Gracias por tu tiempo!

    
pregunta kvanberendonck 06.12.2014 - 00:55

1 respuesta

6

La clave para comprender MVC reside en la separación de responsabilidades, ya que MVC es simplemente SRP aplicado a la IU código. Separa qué datos deben mostrarse, de cómo mostrarlos, de cómo manejar los eventos de pantalla. Pero un detalle importante (ya menudo perdido) de la definición original de MVC es que fue diseñado para un nivel mucho más granular. Por ejemplo, tendría los objetos ButtonModel, ButtonView y ButtonController, "solo" para presentar un solo botón en una pantalla. Falta este detalle es lo que causa tantas opiniones diferentes sobre el tema. Puede consultar la arquitectura de Java Swing para ver a qué me refiero.

El punto de MVC es permitir que el código que sirve a cada responsabilidad se modifique sin afectar el código de los demás. Por ejemplo, podría cambiar la representación de (un componente en) la pantalla sin tener que tocar la representación de datos ni la lógica de manejo de eventos. Entonces, hasta cierto punto, esto va de acuerdo con lo que dices aquí:

  

A partir de esto, razoné que dado cualquier Modelo y Vista, intercambiar solo el controlador no debería cambiar los datos que la página muestra inicialmente porque el controlador debería cambiar solo el comportamiento y no el 'contenido' de la página. Creo que esto se alinea con la visualización conceptual del controlador como un 'controlador de estación' en un sistema ferroviario, un plano del ferrocarril como modelo y la manifestación física real y el aspecto de las pistas (en diferentes versiones, por ejemplo ' Real 'o' Virtual 3D ') como la vista.

Sin embargo, en su contexto, el nivel de granularidad está desactivado; tienes un SessionView que parece ser responsable de una pantalla completa. En este nivel, las responsabilidades se juntan demasiado para separarse por completo según lo previsto por MVC, por lo que es posible que no proporcione los beneficios completos.

Su problema está en separar las tres responsabilidades de UI (representación, datos y manejo de eventos) para las sesiones y los procesos, un total de seis. Debido al nivel de granularidad de los componentes (pantalla completa), esto se vuelve imposible y causa la disonancia en la que se encuentran.

Desea separar las responsabilidades de representación y manejo de eventos tanto para las sesiones como para los procesos, pero uniría sus datos. Su colega quiere desacoplar los datos, pero acoplar el manejo de eventos.

Así que al final, este es un problema de SRP. Mi salida sería disminuir el nivel de granularidad hasta un punto donde pueda separar claramente las Sesiones de los Procesos. Si no puede hacer eso debido a la economía, simplemente tienen que ponderar ambos lados de la compensación, elegir el menos peor y firmarlo como deuda técnica. Esto es, después de todo, de qué se tratan las decisiones de diseño. :)

    
respondido por el MichelHenrich 06.12.2014 - 03:15

Lea otras preguntas en las etiquetas