Algunos antecedentes:
Un colega y yo tenemos diferentes interpretaciones de MVC, lo que significa que, dado el mismo problema, estamos encontrando soluciones radicalmente diferentes. Él viene de un fondo de Java donde cada componente de MVC puede modelar tradicionalmente un objeto y yo vengo de un fondo de Haskell y tengo poca o ninguna experiencia con OOP.
El espacio del problema:
El problema que estamos tratando de 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 Process
que tenga una noción Session
o un vínculo de retroceso.
Sin embargo, una vez que estamos en desacuerdo es el significado central de MVC y cómo eso afecta dónde guardamos 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 debería ser una lista de ProcessController
objetos dentro de los SessionController
cuales a su vez tienen sus modelos como objetos separados dentro de ellos. Esto significa que hay una cantidad significativa de estado dentro de ambos SessionController
y SessionModel
que es relevante para lo que SessionView
necesita renderizar.
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 mayor cambio arquitectónico y parece más difícil de implementar en el código, pero creo que es más conceptualmente correcto. Quisiera que alguien explique por qué este no es el caso, o presente un modelo diferente (si no MVC) que se alinee con esta interpretación y resalte algunas fortalezas y debilidades para 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 puedo leer en Internet, y algunas fuentes dirán cosas como "las vistas, los controladores y los modelos con la misma interfaz deberían ser intercambiables con diferentes efectos". La forma en que imagino que esto funciona es la siguiente:
- Cuando intercambia el modelo, está cambiando la forma en que se validan o almacenan los datos
- Cuando intercambia el controlador, está cambiando el comportamiento de la página , pero no nada que pueda alterar el contenido de los 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 cualquiera Model
y View
, intercambiar solo el controlador no debería cambiar los datos que la página presenta 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 plan de la vía ferroviaria como modelo y la manifestación física real y la apariencia / sensación de las pistas (en diferentes sabores, digamos ' Real 'o' Virtual 3D ') como la vista.
Aquí es donde no estamos de acuerdo:
Argumento que debido a que SessionView
los diferentes procesos en el escritorio cambian los datos que se mostrarán al usuario en el escritorio (modelo los procesos como datos relevantes ), el SessionModel
debe contener la lista de instancias de ProcessModel
. Esto significa que el uso de cualquier aleatorio SessionController
con el mismo SessionView
debería mostrar conceptualmente los mismos datos (procesos en el escritorio).
Argumenta que tiene más sentido para un Model
nunca saber acerca de otro modelo. Esto significa que SessionController
tendría una lista de ProcessController
s dentro y cada Controller
objeto tiene un enlace a su modelo. Dado un SessionView
y el mismo SessionModel
pero diferente, SessionController
los datos que se muestran al usuario deben ser radicalmente diferentes.
Discuta a favor / en contra de cada interpretación y ayúdenos a alcanzar el resultado más informado.
¡Gracias por tu tiempo!