Explicar el controlador de vista de modelo

Mi experiencia con el desarrollo de sitios web dinámicos se limita principalmente a los servlets de Java. He usado Tomcat para desarrollar varios servlets de Java, y no dudaría en decir que soy razonablemente competente con esta tecnología, así como con HTML / CSS / Javascript del lado del cliente para el front-end.

Cuando pienso en "sitio web dinámico", pienso: el usuario solicita una URL con una cadena de consulta, el servidor recibe la consulta y luego procede a generar HTML de forma dinámica para responder a la consulta. Esto a menudo implica la comunicación con una base de datos para obtener los datos solicitados para su visualización. Esta es básicamente la idea detrás del doGetmétodo de Java HttpServlet.

Pero en estos días, escucho cada vez más sobre marcos más nuevos como Django y Ruby on Rails, todos los cuales aprovechan la arquitectura del "Controlador de vista de modelo". He leído varios artículos que explican MVC, pero estoy teniendo problemas para comprender realmente los beneficios. Entiendo que la idea general es separar la lógica de negocios de la lógica de la interfaz de usuario, pero no veo cómo esto es algo realmente diferente de la programación web normal. La programación web, por su propia naturaleza, lo obliga a separar la lógica de negocios (programación del lado del servidor del lado del servidor) de la programación de la interfaz de usuario (HTML o Javascript del lado del cliente), porque los dos existen en esferas de programación completamente diferentes.

Pregunta: ¿Qué ofrece MVC sobre algo como un servlet de Java y, lo que es más importante, qué es exactamente MVC y cómo es diferente de lo que normalmente haría para desarrollar un sitio web dinámico utilizando un enfoque más tradicional como un servlet de Java (o incluso algo más viejo como CGI)? Si es posible, al explicar MVC, proporcione un ejemplo que ilustre cómo MVC se aplica al proceso de desarrollo web y cómo es beneficioso.

Primero, creo que lo mejor es hablar sobre lo que es MVC Architecture y luego profundizar en la forma en que está programando actualmente.

La arquitectura MVC es una forma de organizar el flujo de trabajo dentro de un sistema sotfware, piense en ello como una forma en capas para implementar el comportamiento del sistema. Estas capas son:

1. Modelo : representa su modelo de datos, es el núcleo del sistema donde se debe localizar toda la información relacionada con él. Entonces, por ejemplo: si vas a diseñar un Juego, necesitarás Jugadores, Reglas, Obstáculos y alguna lógica relacionada con las interacciones de estos elementos, tales como: Los jugadores deberían poder ordenar los Obstáculos cuando se aplique algún conjunto de Reglas.

   El modelo es lo primero que debe pensar porque va a ser el centro de sus aplicaciones .

2. Controlador : Aquí es donde ocurre la magia y donde la Arquitectura en capas se encuentra con el Paradigma orientado a objetos que estaba destinado a usar. Aquí es donde implementa cómo reacciona el sistema cuando algún usuario de la aplicación solicita algo sobre la aplicación a través de la interfaz de usuario.

   El controlador debe poder manejar los objetos del modelo, realizar operaciones con ellos para lograr lo que solicitó el usuario y luego delegar el resultado a la capa de vista correspondiente para devolverlo a nuestro usuario.

3. Vista : Este es el punto de inicio y finalización de las interacciones del usuario. Aquí es donde define cómo los usuarios interactúan con la aplicación. Hoy en día es bastante común que los usuarios intenten acceder, por ejemplo, a aplicaciones web de diferentes tipos de medios, tales como: teléfonos móviles, mesas, computadoras, computadoras portátiles, etc.

   En general, cada tecnología necesita un lenguaje diferente para crear la vista, así que imagine que su modelo de datos y la forma en que interactúa ese modelo y cómo representa esas interacciones están codificadas, no hay absolutamente ninguna manera de reutilizar su código de una manera que no sea CopyPaste . El resultado es un código que huele y se pierde mucho tiempo adaptando el sistema HOLE.

   La virtud de tener la Vista en una capa separada, nos permite trabajar independientemente del Modelo en el que estamos trabajando actualmente . Solo necesitamos saber cómo debemos representar la lista de objetos que nos envía el controlador. ¿Cómo lo generó? Es completamente trivial

Entonces, finalmente obtuvimos un modelo independiente que podría adaptarse según lo creamos conveniente de acuerdo con nuestras necesidades actuales (hoy necesito manejar un juego monousuario sin reglas, mañana quiero jugar con amigos y ahora es multiusuario, etc.) eso no depende de cómo lo vamos a presentar al usuario. Luego, un controlador que captura la solicitud de los usuarios que proviene de una vista, procesa objetos de modelo y luego le devuelve la información a la vista para representarla.

Volviendo a la primera pregunta que hizo: Como puede ver (espero) MVC es una MANERA de hacer cosas y no una TECNOLOGÍA para crear software. Puede usar sus Servlets de Java e implementar una MVC Achitecture debajo de ella.

Aquí hay un sitio de ejemplo de preguntas y respuestas que utiliza una arquitectura MVC para aclarar un poco

Para responder tu pregunta

What does MVC offer over something like a Java servlet

MVC es un patrón, no una tecnología. Por lo tanto, el patrón también se puede aplicar cuando está programando con Servlets.

Permítanme tratar de explicar el patrón MVC con los Servlets en sí. Entonces, lo que intenta hacer cuando habla de aplicar MVC es separar el Modelo (la lógica de negocios), la vista (la lógica de presentación) y el Controlador (el Servlet del controlador que delega el control a la lógica de negocios apropiada).

En este caso, MVC no se trata solo de separar el negocio de la capa de presentación y la capa de controlador, sino que la capa de negocio ni siquiera sabe que existe un controlador o una presentación.

Los marcos principales en Java como Struts siguen este patrón. Creo que entendiste mal el concepto. Puedes leer más sobre esto en internet.

MVC es realmente fácil de comprender, es solo un patrón de diseño, sin embargo, he visto que lo más difícil / supervisado es la parte del Modelo.

• Modelo : sus datos (¡no su base de datos exclusivamente !, el modelo puede ser incluso un archivo ini o xml, o datos de un servicio web). Las clases modelo sirven para definir, ensamblar y manejar datos. Lea el excelente artículo llamado " La M en MVC: por qué los modelos son incomprendidos y no apreciados ". El modelo solo debe ser accedido por el controlador.
• Vistas : su código GUI (presentación). Solo debe acceder al controlador
• Controlador : Tu lógica. Maneja la comunicación entre modelo y vista.

El concepto Modelo-Vista-Controlador no es nada nuevo. Comenzó con Smalltalk alrededor de 1979.

En esencia, MVC es una forma de organizar las responsabilidades de su código para que sea modular, predecible y robusto.

La separación le permite las siguientes libertades:

• Capacidad para evolucionar el modelo sin afectar la lógica de la aplicación o mostrar los datos.
• Capacidad para cambiar la lógica de negocios sin afectar el modelo (es decir, agregar nuevos pasos, etc.)
• Capacidad para representar el modelo de múltiples maneras diferentes

Con cuidado, puede diseñar el modelo y el controlador para que pueda reemplazar por completo una aplicación de escritorio con una aplicación web como interfaz.

Más recientemente, el enfoque de Ruby on Rails para MVC introdujo algunos conceptos más nuevos que se copiaron en casi todos los marcos de aplicaciones web de estilo MVC. Esto incluyó los conceptos de "Convención sobre configuración", asignación de acciones del controlador a métodos de clase y enrutamiento de solicitudes de URL al código subyacente.