¿Cuál es el trabajo del controlador en MVC?

Question

Estoy tratando de aprender la arquitectura MVC. Pero no puedo entender por qué necesitas un controlador. Vea el código a continuación para mi modelo y vista.

model.php se conecta a la base de datos y recupera la publicación. view.php solo mostrará la publicación.

modelo.php

<?php 
    $db = mysql_connect("somehostname", "someuser", constant("somepassword")); 
    mysql_select_db("somedatabase", $db); 

    $result = mysql_query("SELECT post FROM posts WHERE postid='" . $_POST['id'] . "'"); 
    $row = mysql_fetch_array($result); 

    $post = $row["post"]; 

    mysql_close($db); 
?> 

view.php

<?php 
    require "model.php"; 
    echo $post; 
?> 

volví mi ubicación navegador para http://whateverhost/view.php?id=5

Esto carga post con el ID 5. Yo no necesito un controlador de aquí . Entonces, estoy confundido, ¿por qué necesitas un controlador?

Nota: Explique con referencia al ejemplo anterior. No soy un fanático de la programación y aprender cosas como CakePHP, etc. es abrumador para mí.

Editar: Sería genial si puede agregar controller.php al código anterior. Eso me ayudaría a entender el rol de un controlador y cómo se comunica con el modelo y las vistas.

Answer 1

No necesita un controlador porque su ejemplo es trivial. Un ejemplo de un caso real:

Supongamos que tiene una aplicación de CAD. La aplicación CAD está organizada como MVC. Tiene:

• una vista que es responsable de dibujar el modelo actual y proporcionar entidades clicables.
• un modelo, que mantiene los datos actuales para ser representados
• controlador, cuya función es obtener los eventos de la vista y convertirlos en entidades adecuadas para modificar el modelo.

Por ejemplo, el usuario hace clic en un cuadrado y lo elimina. El controlador recibirá el evento desde la vista, crea un objeto que representa un comando (a través del patrón de comando), lo agrega a una cola para la función de deshacer y ejecuta el comando. El comando modificará el modelo, pero la responsabilidad de traducir los eventos de visualización en la compleja maquinaria que modifica el modelo está bajo la responsabilidad del controlador.

Por supuesto, podría decir, ¿por qué la vista no crea objetos Command entonces? bueno, nadie te lo prohíbe, pero terminarías teniendo lógica de presentación mezclada con lógica operacional. Esto va en contra del buen diseño, aunque para los casos más triviales, podrías vivir con este diseño. Por ejemplo, si su aplicación CAD le permite mostrar la lista de objetos como una representación 3D y como una lista de entidades, y puede eliminar de ambas, verá claramente que las dos vistas implementan la misma lógica para manejar el patrón de comando (mal diseño), o simplemente canalizan el mismo mensaje a un controlador común (buen diseño, el MVC).

Answer 2

model.php es en este caso su controlador.

Las funciones de modelo, vista y controlador no son fáciles de distinguir si no tiene un buen marco MVC (el PHP simple no es bueno).

El modelo es su estructura de datos que se hace persistente en una base de datos. En términos de código, si consiste principalmente en una estructura de datos como clase.

La vista solo muestra los datos. Principalmente html con algunas etiquetas de scripting.

El controlador controla lo que sucede. Por ejemplo, un usuario edita una publicación. Los datos son recibidos por el controlador, tal vez modificados un poco (marca de tiempo agregada, usuarios IP) y enviados al modelo para almacenarlos. El controlador luego decide qué vista visualizar a continuación y qué datos buscar para la nueva vista.

Solo un pequeño ejemplo.

Answer 3

mi humilde opinión en MVC el controlador tiene dos propósitos principales:

1. El la capacidad de prueba de la lógica de interfaz gráfica de usuario o cualquier cosa que los desencadenantes de la GUI. En la mayoría de los casos, puede escribir pruebas unitarias para el controlador de manera relativamente fácil, es mucho más difícil para GUI como PHP o Windows Forms, por ejemplo. El primero depende de un navegador, el último depende de los mensajes de Windows, ambos no te hacen la vida más fácil cuando escribes pruebas unitarias. Es casi lo mismo con cualquier otra tecnología de capa de presentación.
2. intercambiabilidad de la capa de presentación o (en algunos casos) el controlador. Hay situaciones en las que puede usar el mismo controlador en dos GUI (una forma "ligera" para un caso especial y una forma "rica" ​​para otro) o al revés (no muy a menudo).

En un escenario con mucha más funcionalidad que en su muestra, verá las ventajas. Pero debe decidir a favor o en contra de MVC y usar el mismo enfoque en cada forma de su aplicación, no lo mezcle. Preferiría MVC, casi siempre necesitas lógica de controlador.

Answer 4

Creo que podría haber un uso para un controlador en este caso, y no mostrar el código para ello.

MODELO:

<?php 
    $db = mysql_connect("somehostname", "someuser", constant("somepassword")); 
    mysql_select_db("somedatabase", $db); 

    $result = mysql_query("SELECT post FROM posts WHERE postid='" . $_POST['id'] . "'"); 
    $row = mysql_fetch_array($result); 

    $post = $row["post"]; 

    mysql_close($db); 

function getPost() { 
    return $post; 
} 
?> 

VISTA:

<html> 
<head></head> 
<body> 
    <input type="submit" onClick="postToScreen();" value="Post"> 
    <p id="post"></p> 
</body> 
</html> 

CONTROLADOR:

<?php 
    $controllerPost = getPost(); 
?> 

<script type="text/javascript"> 
function postToScreen() { 
    document.getElementById("post").innerHTML="<?php echo $controllerPost; ?>"; 
} 
</script> 

mi Javascript está oxidado. Creo que obtuve ese código correcto, pero id lo verifico dos veces antes de ponerlo en cualquier cosa. el controlador controla cómo se ve la vista y, en determinadas circunstancias, qué datos contiene el modelo.

Answer 5

OMI ...

MVC es un patrón de diseño muy genérico que no necesariamente decir lo que es bueno y qué es malo. Hay un modelo, una vista y un controlador. Las responsabilidades de cada una de estas cosas dependen del sabor de MVC, y el sabor de MVC que elija debe depender de la complejidad de su proyecto. Por ejemplo, si tiene un proyecto impulsado por dominio, los ejemplos dados por otros aquí no funcionarían muy bien.

Así que en su misma base:

modelo: Un objeto que tiene los datos que se mostrará en la vista. No se define aquí si se trata de un DTO o un modelo de dominio, pero compartiré mis ideas sobre esto en un segundo.

Ver: Es lo que el usuario ve y cómo interactúa el usuario. Cualquier código o lógica aquí debería apoyar directamente la vista. En otras palabras, ZERO business logic, ZERO access access logic, ZERO knowledge of anything más allá de lo que el usuario ve físicamente. Ya sea un formulario web, un formulario de ventana de escritorio o actividad (móvil), etc. ...

Controlador: Probablemente la pieza más ambigua de este rompecabezas. Una cosa es segura, media entre la vista y el "modelo" y también decide qué sucede después o más bien, 'controla' el flujo. Pero es importante no tomar esa descripción demasiado lejos. Lo que hace esto realmente depende de tu comprensión de MVC. Así que compartiré la forma en que lo veo en un contexto web; pero, básicamente, solo trace una línea entre controlar el flujo del servicio y, de hecho, realizar el servicio.

MVC, para mí, no es una forma diferente de describir N-tier, como algunas personas pueden afirmar. No hay capas en MVC como MVC está realmente EN su capa de presentación. Cada elemento de MVC en realidad vive en la capa de presentación y el patrón MVC simplemente dice que debe separar las preocupaciones entre obtener los datos y mostrarlos:

• Modelo: cómo son los datos. En realidad sólo una estructura que la vista usará para obtener sus datos
• Vista: mostrarla realmente
• controlador: Averiguar dónde obtener los datos para el modelo, o incluso el propio modelo.

Si puede aceptar esa afirmación, entonces debería ayudar a aclarar qué es realmente el modelo en este contexto. El modelo NO es un objeto de acceso a datos y el modelo NO es un modelo de dominio porque ninguna de esas cosas debería estar en su capa de presentación. Entonces eso nos deja con un ViewModel (MVVM) o un DTO. Voy a ir con DTO por simplicidad.

Entonces, si hemos aceptado DTO como el tipo de modelo del que estamos hablando cuando decimos "modelo" en MVC, entonces, ¿dónde lo conseguimos? Si el controlador no debe interferir con el acceso a los datos, ¿dónde? ¿Qué hay de su capa de servicio? Su capa de servicio contiene todo el "cómo" de su aplicación. Es la capa "Hacer cosas". Entonces, si su vista quiere crear un usuario, recopilará los datos y se los entregará al controlador. El controlador decide qué servicio (s) llamar para realizar la tarea y le envía la solicitud con los datos necesarios. La capa de servicio responde con un DTO. Ese DTO puede usarse directamente o agregarse a otro modelo (si se llamaron varios servicios, por ejemplo).

Los puntos importantes son:

• El controlador no sabe nada acerca de su dominio (si lo tiene), sólo se sabe acerca de los servicios disponibles y cómo llamarlos.
• Absolutamente no negocio lógica es realizada por el controlador. Por ejemplo, si necesita enviar un correo electrónico de bienvenida como parte de la operación CreateUser, el controlador no lo iniciará ya que técnicamente es una regla comercial. Se manejaría entre su servicio y las capas de dominio.
• En mi opinión, el controlador tampoco debe tener acceso a los datos. Eso debería delegarse en una capa de servicio. Muchos tutoriales tienden a mostrar que el controlador interactúa con los repositorios, lo que supongo que está bien porque es una abstracción, pero el acceso directo a los datos debe ser absolutamente absoluto en la capa de presentación.

Nuevamente, esto en un contexto web. Si estás trabajando con MVC en una aplicación de Android, tal vez no tengas una capa de servicio o un dominio. Quizás interactúes con una clase diferente de objetos. Personalmente, siempre uso las capas de servicio o aplicación, y por varias razones que pueden ser consideradas valiosas o no para otros.

Así que en MVC.Net, el controlador es más como un API; la vista y la API son dos medios de presentación diferentes que deben funcionar juntos (el controlador de fondo presenta datos, el controlador de frontend construye modelos con esos datos y media con la vista). En Angular, el controlador se parece más a lo que estamos hablando aquí. Capas de capas de capas, parece. Es un poco confuso conceptualizar, pero el concepto en realidad nunca se mueve más allá de la capa de presentación.

Pero para resumir: El controlador "controla" las operaciones y los datos que entran y salen de su sistema, y ​​desde el punto de vista pero realidad no hace el negocio. Los detalles de ese proceso dependen en gran medida de su filosofía de diseño para el proyecto.

Así que aquí en este diagrama, He agrupado los conceptos para mostrar MVC dentro de N-capas en una aplicación típica monolítica. La comunicación se ejecuta de izquierda a derecha y no salta sobre ninguna otra capa (ver: Arquitectura de cebolla). En la capa de presentación, el controlador conoce el modelo y la vista, pero la vista y el modelo no saben nada en su mayor parte. Sin embargo, en muchos aspectos de MVC, incluidos ASP.Net y MVVM, la vista puede conocer la interfaz del modelo o el prototipo (pero no la instancia del modelo) para que pueda vincularse.

El controlador manejaría la manipulación del modelo (o vería el modelo en este contexto) lo que significa que podría necesitar conocer el objeto de dominio y los servicios de dominio. Opcionalmente puede insertar una capa de aplicación entre la capa de presentación y el dominio si desea una aplicación más reutilizable (por ejemplo, su aplicación podría tener varias cabezas: una API web y una aplicación de escritorio y una aplicación móvil, etc.) para proporcionar una límite transaccional y mayor aislamiento. Es importante que la vista no tenga conocimiento/dependencia de los objetos de dominio en esta arquitectura, por eso hay un modelo separado para la vista. El objetivo del modelo en MVC es crear un modelo para la vista. Es decir, es un modelo diseñado específicamente para servir a la vista, NO el dominio. Está bien que el modelo de vista ajuste/adapte el modelo de dominio siempre que nunca se exponga públicamente y/o se serialice accidentalmente.

En una nota al margen, la "capa de presentación" en una API web, en mi opinión, es el contrato serializado (por ejemplo, JSON o XML). Entonces trata eso en consecuencia.

Answer 6

Intentaré solo contestar la pregunta en el título. Entonces, ¿cuál es el papel de un controlador en MVC?

trabajo de Es ser un formato modelo para ver Traductor formato con el fin de no tener modelo de interfaz de usuario impulsada y la estructura de base de datos de la interfaz de usuario impulsada.

La idea es desarrollar la estructura de la base lógica de negocio impulsado y luego desarrollar una interfaz de usuario independiente. Ahora cuando agregamos o movemos algún control de UI, nuestro modelo y estructura de base de datos no debe cambiar.