De acuerdo con la página de Wikipedia para la arquitectura MVC , el modelo puede notificar a la vista, y también puede consultar al modelo sobre su estado actual. Sin embargo, de acuerdo con el curso de Paul Hegarty sobre iOS 5 en Stanford, conferencia 1, página 18, toda interacción debe pasar por el controlador, con Model y View que se supone que nunca deben conocerse. No me queda claro si la declaración de Hegarty debe ser una simplificación del curso, pero me siento tentado a decir que tiene la intención del diseño como tal.
¿Cómo explicas estos dos puntos de vista opuestos?
Este es un tema controvertido en MVC / MVVM. Algunos dicen que está bien que la Vista acceda a los Modelos directamente, otros dicen que debe ajustar los Modelos en ViewModels para abstraerlos de la Vista. Personalmente no soy fanático de ninguno de los enfoques.
Uno de los objetivos principales de MVC / MVVM es desacoplar la interfaz de usuario, la lógica empresarial y los datos. Entonces, con ese concepto en mente, permitir que la Vista acceda directamente a los Modelos crea una dependencia que es posible que no desee tener. Por otro lado, envolver los Modelos en ViewModels a menudo es tedioso y no es muy útil ya que los ViewModels tienden a actuar simplemente como un paso a los Modelos.
Me gusta el enfoque de que sus Modelos implementen una interfaz particular, llamémosla IModel. Su clase ViewModel puede ofrecer instancias de objetos que implementen IModel para consumo de vista. La Vista simplemente sabe que funciona con objetos IModel que obtiene del ViewModel. Esto elimina el código de envoltorio ViewModel extraño y oculta la implementación concreta de IModel de la Vista. Posteriormente, puede cambiar una implementación de IModel por otra sin afectar la vista un bit.
Con respecto a los aspectos tediosos de mapear un modelo a un modelo de vista, debe tenerse en cuenta que hay herramientas disponibles que pueden aliviar el dolor de mapeo. EG: (.NET AutoMapper) (JAVA modelmapper)
Jesse
+1 Gran respuesta! Este es un gran enfoque dependiendo de la complejidad de su modelo, pero la mayoría de los modelos actuales son del tipo anémico . Los elementos del modelo, que son poco más que objetos de datos sin comportamiento, veo poca o ninguna necesidad de tal abstracción y poco peligro al permitir que su Vista acceda directamente a su Modelo.
maple_shaft
2
Escucho lo que estas diciendo; la mayoría de las interfaces de IModel simplemente contendrían un montón de declaraciones de propiedades y pocas (si las hubiera) declaraciones de métodos. Pero incluso si los modelos son anémicos, la interfaz sigue desacoplando la vista de su implementación concreta. Es posible que esta separación no sea necesaria para cada proyecto, pero siempre es una buena idea mantener abiertas sus opciones.
Raymond Saltrelli
1
Estoy confundido, si tienes un montón de vistas que son absolutamente diferentes, ¿cómo puedes confiar en una interfaz sin abarrotarla? Creo que los modelos de vista son fantásticos. Usted crea modelos que son lo suficientemente genéricos como para ser utilizados a través de su aplicación y crea modelos de vista para consumir uno o más modelos e implementar operaciones adicionales que solo serían utilizadas por esa vista.
The Muffin Man
12
En la web, todos llaman a su MVC de desacoplamiento.
Algunas tecnologías, como C #, usan MVVM porque no hay un enlace entre la Vista y cualquier otra, todo pasa por el localizador de servicios, vinculando las variables.
En MVC puro, la Vista habla directamente con el Modelo y viceversa. El controlador solo está allí cuando surge algún cambio.
Y luego, está el llamado PAC (Presentation Abstraction Control). En esta arquitectura, la Vista y el Modelo no se hablan entre sí. El controlador es el único que puede hacer algo con la vista o el modelo. La gente a menudo confunde esto con MVC.
Para mí, el objetivo básico de una arquitectura es que no impida futuros intentos de refactorización. Por lo general, las vistas que interactúan directamente con los modelos coinciden con este requisito, y es relativamente claro cuando no lo hace.
Cuando una vista se vuelve demasiado íntima con un modelo, un ViewModel puede ser algo hermoso, pero generalmente es el caso para mí que las instancias donde se solicita son minoritarias.
En MVC , Paul Hegarty está equivocado. El controlador trata sobre los eventos del usuario, no la comunicación del modelo para ver. En MVC clásico , las vistas observan el modelo (patrón de observador).
Con el tipo en medio haciendo la mediación, el patrón debería llamarse MVP , y de hecho, la mayoría de lo que hoy se presenta como MVC, de hecho, está más cerca del MVP.
Luego está MVVM, que es algo similar a ambos, pero un poco diferente, y existió hace mucho tiempo ... es mejor verlo como dos MVC / MVP unidos entre sí a través del objeto viewmodel: el MVC "cliente" tiene viewmodel como su modelo, y el "servidor" MVC tiene el modelo de vista como su vista.
Hoy (principios de 2014), para mí (con mi nodo y pila angular), esta distinción en MVC "cliente" y MVC "servidor" me parece muy relevante y de alguna manera esclarecedora. (gracias)
slacktracer
4
Dado que está preguntando sobre el material en esas conferencias de Stanford en particular, vale la pena considerar dos cosas sobre la postura de Hegarty:
Como has mencionado, él está enseñando un curso de informática de nivel 100. Hay muchos lugares en sus conferencias donde simplifica, pasa por alto los detalles o dice "simplemente hazlo de esta manera", como probablemente tengas que hacer cuando enseñas lo básico, es decir, debes dominar las reglas antes de poder romperlas.
Mi experiencia con el SDK de iOS es que, donde no exige una separación estricta entre View y Model, está orientada en gran medida hacia ese patrón. Al escribir aplicaciones iOS en particular, cumplir con la separación de vista de modelo le ayuda a escribir código que esté en línea con las expectativas del marco. Dudaría en generalizar las declaraciones de Hegarty al desarrollo en otras plataformas o en general.
Estoy de acuerdo con Paul Hegarty y creo que la Vista no debe saber sobre el Modelo. No es tan difícil de lograr, pero aporta beneficios adicionales a su diseño y flexibilidad futura.
En aplicaciones pequeñas (generalmente de escritorio) donde me gustaría evitar las clases "falsas" de ViewModel y mantener las cosas simples, también uso la interfaz IModel (ver la respuesta anterior) y me aseguro de que Model no tenga idea de la vista (use suscriptores como en el MVC clásico).
También en este caso, el Controlador está bastante acoplado con la Vista y, por simplicidad, no siempre los separo claramente.
El segundo enfoque "simplificado" está bien cuando puede tener varias vistas para el mismo modelo, pero no lo recomendaría si desea utilizar la misma vista para diferentes modelos. Bajo diferente quiero decir realmente diferente por naturaleza y no solo las clases de prueba JUnit que "siguen" el modelo principal.
Creo que no hay una regla dura y rápida para esto, depende totalmente de sus necesidades.
Encontrarás personas con diferentes creencias. Las arquitecturas son conceptos para ayudar a diseñar mejores soluciones.
Además de la comunicación de vista de modelo, hay una contradicción más sobre la lógica de negocios en MVC. Muchas personas creen que toda la lógica de negocios debería ser un modelo (ver esta pregunta SO ), por otro lado, el enlace compartido por Florian (en su respuesta) dice que la lógica de negocios debería estar en el controlador.
Aparte de esto, existe la posibilidad de dividir la lógica empresarial en la lógica de la aplicación (ponerla en el controlador) y el inicio de sesión en el dominio (ponerla en el modelo).
Entonces, la moraleja de la historia es que MVC significa que el modelo, la vista y el controlador deben estar separados. Aparte de eso, lo que más te convenga.
Estoy con el campamento que dice que la vista nunca debe comunicarse con el modelo. El controlador siempre debe ser el tipo de referencia para todo, luego decide qué hacer (validar, solicitar datos del modelo, etc.).
Tiendo a verlo más como un problema de organización que cualquier otra cosa.
Se sugieren muchos sobre por qué y cómo view & model debería interactuar libremente en diferentes contextos, pero la razón principal en iOS para hacer que Controller sea el mediador entre ellos es evitar las dependencias de Model & View en su base de código y permitirnos reutilizar ya sea modelo o vista de acuerdo con los requisitos con la evolución de iOS.
Como es posible que necesitemos mantener actualizaciones de nuestras aplicaciones en UI / UX o Model o algunas veces en ambas, no debería producir un código de dependencia de modo entre modelo y vista. Si desea cambiar la capa de Presentación de su aplicación, simplemente vaya y cámbielo para poder reutilizar el mismo modelo y viceversa.
Aunque estoy de acuerdo en que MVC en iOS produce ViewControllers gigantes con muchas lógicas diferentes y maneja todo tipo de cosas que no sean para lo que está destinado, por lo que es mejor usar MVVM o controles de presentación para hacer que su base de código sea más flexible y fácil para leer y mantener con ViewControllers más pequeños.
Esto podría ayudar a quienes buscan ViewControllers más pequeños en iOS:
En la web, todos llaman a su MVC de desacoplamiento.
Algunas tecnologías, como C #, usan MVVM porque no hay un enlace entre la Vista y cualquier otra, todo pasa por el localizador de servicios, vinculando las variables.
En MVC puro, la Vista habla directamente con el Modelo y viceversa. El controlador solo está allí cuando surge algún cambio.
Y luego, está el llamado PAC (Presentation Abstraction Control). En esta arquitectura, la Vista y el Modelo no se hablan entre sí. El controlador es el único que puede hacer algo con la vista o el modelo. La gente a menudo confunde esto con MVC.
Verá una explicación mucho mejor aquí: http://www.garfieldtech.com/blog/mvc-vs-pac
fuente
Para mí, el objetivo básico de una arquitectura es que no impida futuros intentos de refactorización. Por lo general, las vistas que interactúan directamente con los modelos coinciden con este requisito, y es relativamente claro cuando no lo hace.
Cuando una vista se vuelve demasiado íntima con un modelo, un ViewModel puede ser algo hermoso, pero generalmente es el caso para mí que las instancias donde se solicita son minoritarias.
fuente
En MVC , Paul Hegarty está equivocado. El controlador trata sobre los eventos del usuario, no la comunicación del modelo para ver. En MVC clásico , las vistas observan el modelo (patrón de observador).
Con el tipo en medio haciendo la mediación, el patrón debería llamarse MVP , y de hecho, la mayoría de lo que hoy se presenta como MVC, de hecho, está más cerca del MVP.
Luego está MVVM, que es algo similar a ambos, pero un poco diferente, y existió hace mucho tiempo ... es mejor verlo como dos MVC / MVP unidos entre sí a través del objeto viewmodel: el MVC "cliente" tiene viewmodel como su modelo, y el "servidor" MVC tiene el modelo de vista como su vista.
fuente
Dado que está preguntando sobre el material en esas conferencias de Stanford en particular, vale la pena considerar dos cosas sobre la postura de Hegarty:
fuente
Estoy de acuerdo con Paul Hegarty y creo que la Vista no debe saber sobre el Modelo. No es tan difícil de lograr, pero aporta beneficios adicionales a su diseño y flexibilidad futura.
En aplicaciones pequeñas (generalmente de escritorio) donde me gustaría evitar las clases "falsas" de ViewModel y mantener las cosas simples, también uso la interfaz IModel (ver la respuesta anterior) y me aseguro de que Model no tenga idea de la vista (use suscriptores como en el MVC clásico).
También en este caso, el Controlador está bastante acoplado con la Vista y, por simplicidad, no siempre los separo claramente.
El segundo enfoque "simplificado" está bien cuando puede tener varias vistas para el mismo modelo, pero no lo recomendaría si desea utilizar la misma vista para diferentes modelos. Bajo diferente quiero decir realmente diferente por naturaleza y no solo las clases de prueba JUnit que "siguen" el modelo principal.
fuente
Creo que no hay una regla dura y rápida para esto, depende totalmente de sus necesidades.
Encontrarás personas con diferentes creencias. Las arquitecturas son conceptos para ayudar a diseñar mejores soluciones.
Además de la comunicación de vista de modelo, hay una contradicción más sobre la lógica de negocios en MVC. Muchas personas creen que toda la lógica de negocios debería ser un modelo (ver esta pregunta SO ), por otro lado, el enlace compartido por Florian (en su respuesta) dice que la lógica de negocios debería estar en el controlador.
Aparte de esto, existe la posibilidad de dividir la lógica empresarial en la lógica de la aplicación (ponerla en el controlador) y el inicio de sesión en el dominio (ponerla en el modelo).
Entonces, la moraleja de la historia es que MVC significa que el modelo, la vista y el controlador deben estar separados. Aparte de eso, lo que más te convenga.
fuente
Yo uso DTO para la comunicación modelo-vista.
Por ejemplo:
fuente
Estoy con el campamento que dice que la vista nunca debe comunicarse con el modelo. El controlador siempre debe ser el tipo de referencia para todo, luego decide qué hacer (validar, solicitar datos del modelo, etc.).
Tiendo a verlo más como un problema de organización que cualquier otra cosa.
fuente
Se sugieren muchos sobre por qué y cómo view & model debería interactuar libremente en diferentes contextos, pero la razón principal en iOS para hacer que Controller sea el mediador entre ellos es evitar las dependencias de Model & View en su base de código y permitirnos reutilizar ya sea modelo o vista de acuerdo con los requisitos con la evolución de iOS.
Como es posible que necesitemos mantener actualizaciones de nuestras aplicaciones en UI / UX o Model o algunas veces en ambas, no debería producir un código de dependencia de modo entre modelo y vista. Si desea cambiar la capa de Presentación de su aplicación, simplemente vaya y cámbielo para poder reutilizar el mismo modelo y viceversa.
Aunque estoy de acuerdo en que MVC en iOS produce ViewControllers gigantes con muchas lógicas diferentes y maneja todo tipo de cosas que no sean para lo que está destinado, por lo que es mejor usar MVVM o controles de presentación para hacer que su base de código sea más flexible y fácil para leer y mantener con ViewControllers más pequeños.
Esto podría ayudar a quienes buscan ViewControllers más pequeños en iOS:
http://blog.xebia.com/simplification-of-ios-view-controllers-mvvm-or-presentation-controls/
fuente