General en mvc ... ¿debería el controlador pasar datos para ver o ver debería tomarlo directamente del modelo?

Question

Estoy tratando de aprender y comprender completamente el patrón de mvc y aprender php al mismo tiempo. Decidí construir un framework básico de mvc que podría usar en varios proyectos más adelante. Después de haber leído muchas publicaciones aquí sobre mvc y acoplamiento entre modelos/vistas/controladores, estoy un poco perdido. Por el momento, tengo entendido que los controladores de aplicaciones web se ocupan de la próxima solicitud del navegador y, si es necesario, llama a los métodos. clases modelo que indican a los modelos que cambien su estado. Luego, el controlador instanciará la clase de vista apropiada que será responsable de mostrar la interfaz. Aquí está la parte que no entiendo ...

1. Ahora debe pasar controlador objeto de modelo apropiado para ver y la vista debe sacar todos los datos de modelo cuando sea necesario?

2. o controlador debe tomar los datos de modelo y pasarlo a ver, posiblemente envolviendo todo en un solo objeto envoltorio que ver accederá a los datos de agarre y desde allí?

3. ¿O debería simplemente crear una instancia del modelo apropiado cuando sea necesario y extraer datos directamente del objeto modelo?

Por lo que he leído aquí

http://www.phpwact.org/pattern/model_view_controller

Me inclino por la tercera opción donde el controlador no pasa nada para ver y vistas instancia modelo que necesita. Esto es porque:

1. vista y el controlador deben tener el mismo acceso a modelar

   controlador

2. no debe actuar simplemente como mediador en entre la vista y el modelo.

¿Existe realmente una manera correcta de hacerlo o más bien depende del proyecto? Además, ¿qué enfoque recomendaría a alguien que tenga una comprensión decente de OOP, pero que sea relativamente nuevo en php y no demasiado claro en la arquitectura de mvc? O tal vez debería ir con lo que sea correcto para mí y aprender de mis errores (aunque me gustaría evitarlo);

Ahora, hágamelo saber si mi pregunta no es clara, trataré de explicar mejor entonces ... También leo muchas publicaciones en stackoverflow y numerosos artículos en diferentes sitios, pero aún agradecería ayuda, así que gracias de antemano por todos respuestas

Answer 1

Personalmente, siempre he sido un defensor de # 3. La vista no debería preocuparse por el controlador. La vista no debería tener ninguna dependencia en el controlador para ese asunto. Debería hacer lo que se supone que debe hacer, mostrar una vista del modelo.

El flujo de control básico debe ser el siguiente: El controlador recibe una solicitud de un navegador. Realiza cualquier actualización del modelo, que sea relevante, y luego selecciona una vista. El control se pasa luego a la vista, que obtiene datos del modelo y lo renderiza.

Como una extensión, la entrada del usuario se puede considerar parte del modelo, y tanto el controlador como la vista pueden leer de ella. El punto clave que se debe quitar es que el Controlador y la Vista no deberían tener dependencia entre sí. Es por eso que el patrón se llama MVC.

Ahora, personalmente, considero que MVC es un poco tedioso, por lo que normalmente confundo Controller y View more than this. Pero eso no es realmente MVC.

Answer 2

Personalmente, siempre he sido un defensor de # 2. La vista no debería preocuparse por el modelo. La vista no debería tener ningún procesamiento en absoluto para ese asunto. Debería hacer lo que se supone que debe hacer, formatear datos.

El flujo de control básico debe ser el siguiente: El controlador recibe una solicitud de un navegador. Procesa la solicitud, decide qué datos se necesitan y la recupera de los modelos. A continuación, pasa los datos a la vista que formatea los datos y los muestra.

Como una extensión, la entrada del usuario se procesa dentro del controlador y se guarda en un modelo si es necesario, la retroalimentación se alimenta a una vista, etc. El punto clave es que el procesamiento ocurre dentro del controlador.

Answer 3

Tuve una pregunta muy similar anteriormente.Me parece útil pensar en ello como sigue:

MVC 
Model -- Data store, alerts Views of changes 
View -- Displays model, provides hooks for user interaction 
Controller -- Handles user input 

Se podría utilizar MVC más a menudo en aplicaciones no web, donde la gran cantidad de clases están interactuando entre si simultánea.

En una aplicación web MVC significa MVT (Modelo-Vista-Plantilla)

Model -- Strictly a data store, typically an ORM solution 
View -- Handles web requests, provides for user input/output 
Template -- Actually displays content (HTML, Javascript, etc.) 

Así que en una aplicación web la presentación se maneja en la plantilla, la lógica de la aplicación se maneja en la vista (o clases llamadas por la vista), y el modelo es responsable de mantener los datos.

Answer 4

Web MVC y Desktop MVC son dos bestias muy diferentes.

En Web MVC, un enlace en una vista llama a un método en un controlador, que actualiza un modelo y luego redirige a una vista adecuada, lo que abre un modelo y muestra lo que necesita.

En un escritorio MVC, la opción 3 es incorrecta porque tanto la vista como el modelo deben usar la misma referencia. En la web, no hay otra opción.

La opción número 2 no es MVC. Es MVP, en donde el Presentador es un mediador.

Un controlador tiene acceso de escritura a un modelo; una Vista tiene solo acceso de Lectura.

Answer 5

Esta es una pregunta muy interesante. de mi experiencia la mayoría de las implementaciones en php asignar una variable del modelo a la vista:

$this->view->my_property = $modelObj->property 

Ésta es una práctica común. El razonamiento común para esto es que si envía el objeto, puede llamar a los métodos que modifican el objeto desde la vista.

//in the controller file 
$this->view->myObject = $modelObj; 

//in the view file, you could call an object modifying method 
$this->myObject->delete(); 

Y la modificación del modelo de la vista se considera una mala práctica. Algunas personas creen que no quieren que sus diseñadores puedan llamar a los métodos de modificación del modelo desde la vista.

Dicho eso. I no estoy de acuerdo con la práctica común y tiendo a asignar todo el objeto a la vista y mostrarlo desde allí. Y solo me disciplino para no hacer operaciones allí.

Y una tercera opción es asignar el objeto completo a la vista. pero de alguna manera en los objetos deshabilitar los métodos cuando se llaman desde la vista.

Answer 6

Tiendo a que el controlador actúe como un intermediario entre el modelo y la vista, pero generalmente esto es literalmente una sola línea de código que conecta los tres juntos. Si su modelo, vista y controlador están desacoplados correctamente, debería hacer muy poca diferencia que use.

Answer 7

creo que esto es sólo un genérico discuten sobre lo que es mejor "empuje" o"tirar" modelo. No hay una "mejor" solución.

Answer 8

La razón por la que muchos desarrolladores de hoy en día no se puede conseguir el golpe de MVC es debido a que la abreviatura de MVC fue incorrectamente desde el primer día cuando llegó en el desarrollo de software, pero el concepto es correcto en ese entonces y también hoy. Como soy de la vieja escuela, déjame explicarte por ti; cuando crea un objeto, primero crea un Modelo para que el cliente lo pueda ver. Una vez que se aprueba, tendrá control total sobre cómo se va a hacer el objeto. Así es hasta hoy en la fabricación de productos.

En el desarrollo actual de aplicaciones web, dicho término debe ser VCM. ¡Por qué! Usted ve lo que está en el navegador web, y luego hace clic en un botón para la acción, que se conoce como el Controlador. El controlador alerta al Modelo, que es la instrucción o lógica para producir un resultado (esa es su secuencia de comandos). El resultado luego se envía al usuario para su visualización. En ingeniería de software, puede referirse a él como CMV; porque el usuario no podrá ver nada hasta que las aplicaciones estén compiladas e instaladas. Por lo tanto, necesitaremos un dispositivo de control (PC); el sistema operativo como modelo y un monitor para ver los resultados. Si puede entender esos conceptos, MVC debería comenzar a verse mucho más apetecible. Espero que este concepto ayude a alguien a entender MVC.