model view controller - patterns - ¿Cómo funciona un sistema MVC?

mvc frameworks

Question

Estoy tratando de aprender el patrón MVC, pero cada lugar dice algo diferente. Así que ahora no sé cuál es el verdadero MVC.

Así que supongo que es el MVC más puro:

• El modelo es solo datos y notificar cambios de datos.
• La vista lee los mensajes del modelo para actualizar la vista.
• El controlador lee la entrada del usuario desde Ver y cambia el modelo según sea necesario.

Implementar

• La modelo no conoce a nadie.
• La vista conoce el modelo .
• El controlador conoce tanto la vista como el modelo .

Pseudocódigo

/* Model */
class Color{ 
  color = blue;
  setColor(color);
  notifyUpdate();
}
/* View */
class ColorPicker(model){
  model.register(update);
  update(){
    this.colorToExhibit = model.color;
  }
}
/* Controller */
class Colorize(view, model){
  view.register(update);
  update(color){
    model.setColor(color);
  }
}

Algunas preguntas:

1. ¿Está bien?
2. No puedo ver por qué la Vista no puede cambiar el Modelo directamente, sino a través del Controlador.
3. Supongamos que tengo animaciones para realizar después de una acción. ¿Quién debe manejar esta animación: el modelo, la vista o el controlador? Además: ¿la lógica de animación es parte del modelo, vista o controlador? Más: Supongamos un juego de poker. Después de que el usuario elija una acción (por ejemplo, ''Levantar''), el sistema debe reproducir una animación (por ejemplo, las fichas que van del jugador al escritorio). ¿Cómo puedo ver este ejemplo de póker (con animación) como un MVC? ¿Puedes explicar y dar un pseudocódigo al respecto?

Gracias.

Answer 1

• El modelo es solo datos y notificar cambios de datos.
• La vista lee los mensajes del modelo para actualizar la vista.
• El controlador lee la entrada del usuario desde Ver y cambia el modelo según sea necesario.

El modelo es más que solo datos. El modelo es también la lógica empresarial. Contiene toda la inteligencia del sistema, o al menos una abstracción de la inteligencia detrás de escena (como las llamadas a bases de datos u otras llamadas de servicio). Considere el dicho: "Mantenga sus modelos pesados ​​y sus controladores livianos".

• La modelo no conoce a nadie.
• La vista conoce el modelo.
• El controlador conoce tanto la vista como el modelo.

El Modelo no conoce a nadie, que lo corrija. El modelo debe ser portátil entre las aplicaciones y no debe depender de las preocupaciones de la UI de ninguna manera. (La vista y el controlador son problemas de UI en este caso).

La vista conoce el modelo, también correcta. La vista básicamente "se une" al modelo. Presenta todos los elementos de la interfaz de usuario y coloca los datos del modelo dentro de los elementos de la interfaz de usuario en consecuencia.

El tipo de controlador de "conoce la vista". Sabe qué Vista a la que debería dirigir el control, pero no sabe nada acerca de esa Vista. Tampoco sabe qué Vista desde qué control vino anteriormente. El controlador responde a los eventos. Un evento viene de la interfaz de usuario, llevando consigo algún tipo de información de estado (un ViewModel, tal vez), dirige el control lógico a través de los Modelos (donde ocurre la lógica de negocios), y responde con un Modelo (o un ViewModel, si la forma de los datos específicos de una vista particular es diferente de los modelos) y una vista.

No puedo ver por qué la Vista no puede cambiar el Modelo directamente, sino a través del Controlador.

La Vista puede manipular el Modelo dentro del contexto de la interacción del usuario, pero no debe esperar que esos cambios persistan de ninguna manera. La vista debe considerarse "del lado del cliente" y no sabe nada del "lado del servidor". (Incluso si está hablando de una aplicación nativa y no de una aplicación web). La persistencia de cualquier cambio se considera una "acción" o "evento" de la interfaz de usuario e iría a un Controlador para que esto suceda.

Supongamos que tengo animaciones para realizar después de una acción. ¿Quién debe manejar esta animación: el modelo, la vista o el controlador? Además: ¿la lógica de animación es parte del modelo, vista o controlador?

Una animación suena como una operación totalmente basada en la interfaz de usuario. Estaría dentro de la vista. ¿Hay algo más que una simple animación UI? ¿La animación cambia algo en el back-end? Por ejemplo, si tengo una aplicación web y, cuando se carga una página, quiero introducir algunos datos (una animación) ... eso está completamente en la Vista. Los datos se enviarían a la Vista como cualquier otro dato, y la animación se realizará completamente dentro de la interfaz de usuario (Vista). No hace nada desde la perspectiva del Modelo o del Controlador.

Supongamos un juego de poker. Después de que el usuario elija una acción (por ejemplo, ''Levantar''), el sistema debe reproducir una animación (por ejemplo, las fichas que van del jugador al escritorio). ¿Cómo puedo ver este ejemplo de póker (con animación) como un MVC? ¿Puedes explicar y dar un pseudocódigo al respecto?

La acción ("Elevar") es un evento de Controlador. La interfaz de usuario se pondría en contacto con el controlador para realizar el "aumento". Entonces, el Controlador podría tener un método como este:

View Raise(GameState state)
{
    // Interact with the Models to update the known state of the game.
    // The Models would perform the actual Poker game logic.
    // Respond with a View bound to updated Models.
}

Una vez que el Controlador responda a la IU con una nueva Vista, esa Vista contendrá cualquier animación para mostrarle al usuario. (Después de todo, no desea realizar la animación a menos que la acción haya sido exitosa, ¿verdad? Cuando el Controlador responde a la interfaz de usuario con una nueva Vista que indica una acción exitosa, entonces la animación se reproducirá. En cambio, puede responder a la interfaz de usuario con una Vista que indica un error, en cuyo caso esa Vista mostraría algo más.)

Answer 2

Iré con la simple analogía del banco.

• Los cajeros son vistas.
• Los corredores son controladores.
• Los banqueros son modelos.

Los banqueros son los inteligentes, conocen toda la lógica empresarial y hacen todos los cálculos complejos.

Los corredores se utilizan para transportar el dinero (datos) de los banqueros a los cajeros.

El Cajero presenta el dinero al Cliente.

Una simple representación:

Modelo

public class BankAccount
{
     public int ID;
     public int Balance;

     public BankAccount(int id)
     {
         ID = id;
         Balance = DetermineAmount();
     }

     public int DetermineAmount()
     {
         // Gather transaction info, debits, credits and return a
         // sum of the amount left in the account depending on the
         // id provided.
     }
}

Controlador

    public class BankAccountController
    {

         public ViewResult Index(int id)
         {
             BankAccount account = new BankAccount(id);
             return View(account);
         }

    }

Ver

<ul id="account-info">
   <li>Account ID: `@Model.ID`</li>    
   <li>Balance: `@Model.Balance`</li>
</ul>

Answer 3

Si está interesado en el verdadero MVC histórico, comience con Trygve Reenskaug . Lo creó (¿lo observó, lo catalogó?) A fines de los años setenta. Para empezar, lea "Models-Views-Controllers" de 1979. Define la terminología. Tome buena nota de su título: los tres roles están pluralizados . Esto es lo primero que la mayoría de la gente parece equivocarse.

La mejor descripción que he encontrado del uso original de MVC es en realidad en una presentación de 2004 titulada "Inside Smalltalk MVC" . Supongo que los documentos canónicos que describen la versión final de Smalltalk 80 de MVC son "Un libro de recetas para usar el paradigma de interfaz de usuario de modelo-vista-controlador en Smalltalk-80" y la st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html Steve Burbeck st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html . Ambos papeles bien merecen la lectura.

Si tienes tiempo para matar y no te importa escuchar a Robert Martin, hizo una buena nota en Ruby Midwest 2011 que tocó en MVC. Es un poco más de una hora, pero bastante entretenido y esclarecedor. Tiendo a seguir con su opinión de que la mayoría de las implementaciones hacen que MVC esté equivocado. Pasé un poco de tiempo mirando a mi alrededor y, finalmente, encontré un diagrama que puedo vincular al que describe MVC. El que me gusta vino de Pope y Krasner .

MVC http://www.as3dp.com/wp-content/uploads/2010/02/mvc_pope_krasner.png

Desde mi punto de vista, los siguientes son los puntos clave:

• una instancia de modelo es responsable de notificar los objetos interesados de cambios . Tenga en cuenta que estas pueden ser cualquier instancia de objeto. El diagrama muestra las vistas y los controladores que reciben actualizaciones aquí.
• Las vistas son responsables de consultar el estado actual y mostrar los resultados . Por lo general, también realizan el filtrado o la transformación de datos.
• los controladores son responsables de aceptar la entrada del usuario y reenviar mensajes de vista a lo largo de la vista.
  • Ver mensajes es un tema común en MVC. Es importante que sean independientes del mundo de la interfaz de usuario; no se trata de clics con el mouse y, lo que no, es un lenguaje de eventos específico para cada vista. Esto nos lleva al siguiente punto.
• La vista no depende del controlador de ninguna manera . Los controladores son responsables de organizar y crear vistas y proporcionar la interfaz entre el resto del mundo y la vista.
• En un mundo perfecto, la vista es responsable de hacer visible la representación del modelo . Así es como funcionó cuando se aplicó MVC a las aplicaciones de escritorio.

La realidad es que MVC ha sido retorcido y reescrito para el mundo web. En realidad ya no es MVC o quizás MVC simplemente se redefinió. Esta es la razón por la que están viendo tantas opiniones y representaciones diferentes de MVC por ahí. Si estás pensando en escribir aplicaciones de estilo de escritorio, mira las cosas de Krasner & Pope. Si está investigando cómo se aplica MVC a la web, entonces recomiendo la nota clave de Uncle Bob para una alternativa que se adapte mejor a las aplicaciones web: lo que él llamó Interactor, Entidad, Arquitectura de límites por falta de un nombre mejor. Busca cosas relacionadas con sus charlas sobre "Los años perdidos de la arquitectura" .