MVC: Controlador de vista de modelo: ¿la vista llama al modelo?

Question

He estado leyendo acerca del diseño de MVC desde hace un tiempo y parece oficialmente que View llama a objetos y métodos en el Modelo, crea y genera una vista.

Creo que esto es principalmente incorrecto.

El controlador debe actuar y recuperar/actualizar objetos dentro del modelo, seleccionar una vista adecuada y pasarle la información para que se muestre. Solo las variables de PHP básicas y rudimentarias/simples deben aparecer dentro de la Vista.

Si la Vista obtiene la información que necesita para mostrarse desde el Modelo, seguramente habrá una gran cantidad de PHP dentro de la Vista, violando por completo el punto de separación de la lógica de presentación.

Answer 1

Como en todos los programas, debemos ser pragmáticos. Una vista solo debe contener lógica de presentación. Esa lógica puede ser muy simple o puede ser bastante compleja. Siempre que esa lógica solo maneje lo que se muestra en la pantalla, impresa en el informe, etc.

El controlador debe actuar y recuperar/actualizar objetos dentro del modelo, seleccionar una vista apropiada y pasarle la información para que pueda mostrarse

¿Qué información está transmitiendo? Posiblemente un subconjunto de un modelo. Puede crear una nueva clase que contenga solo la información que la vista debe conocer o simplemente pasar el modelo y asegurarse de que solo acceda a los datos apropiados. De todos modos, la vista debe ser libre de consultar este modelo pasado para poder mostrar una vista.

El punto de controversia es si desde la vista debería poder actualizar el modelo directamente, sin pasar por el controlador. Aquí es donde entra el lado pragmático. Creo que hay casos que pueden justificar la actualización del modelo directamente. Especialmente si puedes usar enlaces de datos. Puede asignar un cuadro de texto a una propiedad del modelo y dejar que la actualización se realice automáticamente. Si hay muchas configuraciones simples de propiedad, este enfoque puede ahorrar un montón de código en el controlador. MVC no es un conjunto de reglas establecidas en piedra. Es una guía que cuando se usa correctamente puede producir un mejor código, pero si se usa con demasiada rigurosidad, puede provocar dolor y sufrimiento.

Sea pragmático!

Answer 2

MVC no es una ley en piedra. Dependiendo de dónde lo lea, puede diferir. Personalmente no permito que la Vista lea directamente del Modelo.

Actualización Este post tiene algunos buenos ejemplos también. El modelo es el motor del automóvil con métodos de inicio(), la vista es del color del automóvil con los métodos paint() o change() y el controlador es el controlador. Prefiero dejar que el controlador impulse() el automóvil y encienda() el motor en lugar de dejar que las ruedas o la pintura lo hagan.

:)

Answer 3

No hay una manera absoluta y correcta de hacer MVC. Las variaciones son posibles

Por ejemplo, en lugar de tener la vista consultando activamente el modelo, el controlador puede notificar a la vista de cualquier cambio en el modelo, utilizando algún tipo de mecanismo de notificación. En ese caso, la Vista solo está escuchando las actualizaciones, que luego se presentan.

Answer 4

MVC se refiere a las capas, no a los componentes. Entonces, son conceptos más abstractos que los planos. Dado que no es posible separar las capas por completo (la información tiene que fluir entre ellas), en realidad es un continuo donde tienes spaghetti en un extremo y sistemas de tipo burocrático en el otro. Probablemente quieras encontrar algo entre esos dos.

Por lo general, no me esfuerzo demasiado en la separación de la vista del controlador. La separación entre el modelo y (vista de controlador) es mucho más importante.

Answer 5

Creo que tiene toda la razón: las vistas no deben llamar a los métodos de los Modelos. Como otros dijeron, hay variaciones en MVC pero el punto es separar la lógica de los datos de la salida.

Por lo general, usted tiene un controlador que es el punto de partida para la aplicación. En PHP, este sería su archivo index.php. Como mínimo, este archivo procesaría los datos de entrada (es decir, la cadena de consulta o los parámetros de URL). Por lo general, es una buena idea agregar controladores separados para partes separadas de la aplicación.

Cada controlador simplemente decide qué datos se deben mostrar, lo obtiene del modelo y lo pasa a la vista. En PHP, debe llamar a varias clases/métodos que obtienen datos de la base de datos, almacenándolos en variables.

Luego simplemente incluye otro archivo PHP que contiene principalmente HTML, pero con algunas variables de eco de PHP. Los bucles también están bien.Si usted tiene una lista de las cosas, es posible que desee hacer algo como esto:

<ul> 
<?php foreach ($items as $item) : ?> 
    <li><?=$item?></li> 
<?php endforeach; ?> 
</ul> 

Answer 6

Probablemente no es lo que uno llamaría "puro" MVC, pero en mi humilde opinión no es un gran problema, siempre y cuando el código PHP vista no muta el modelo La regla más importante de MVC es que el modelo no sabe acerca de la vista. Tener la vista no saber sobre el modelo es menos importante.

La desventaja principal de usar el modelo directamente es que la vista no se puede reutilizar con un modelo diferente. Esto rara vez es un problema, porque la vista casi siempre es específica para un tipo particular de objeto modelo (o una lista de los mismos).

Answer 7

¿Las siguientes modificaciones a DisgruntledGoat's code snippet se considerarían demasiado "complejas"? ¿Deben pasar los objetos a la vista?

<li><?=$item->description?></li> 

¿O quizás?

<li><?=$item->getDescription()?></li> 

He visto varios ejemplos en los que sólo se utilizan matrices: -

<li><?=$item['description']?></li>