Explain Model View Controller

Para responder a 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 se puede aplicar cuando estás programando con Servlets también.

Permítame tratar de explicar el patrón MVC con los Servlets. Entonces, lo que está tratando de hacer cuando habla sobre la aplicación de 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). p>

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

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

Primero creo que es mejor hablar sobre qué es la arquitectura MVC y luego profundizar en la forma en que estás programando actualmente.

La arquitectura MVC es una forma de organizar el flujo de trabajo dentro de un sistema sotfware, piénselo como una forma en capas de 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. Por ejemplo, si va a diseñar un Juego, necesitará Jugadores, Reglas, Obstáculos y cierta lógica relacionada con las interacciones de estos elementos, como por ejemplo: Los jugadores deberían poder clasificar Obstáculos cuando se apliquen algunas reglas.

   El Modelo es lo primero que debes pensar porque va a ser el centro de tus aplicaciones .

2. Controlador : aquí es donde ocurre la magia y donde la arquitectura en capas cumple con el paradigma orientado a objetos que se pretendí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 de modelo, hacer   operaciones con ellos para lograr lo que   El usuario solicita y luego delegar.   El resultado a la vista correspondiente.   Capa para devolverlo a nuestro usuario.

3. View : Este es el punto de inicio y fin de las interacciones del usuario. Aquí es donde se 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, tablas, PC, 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 y la forma en que se procesan esas interacciones están totalmente codificadas, no hay absolutamente ninguna manera de reutilizar su código de una manera que no es CopyPaste. El resultado es un código que huele y mucho tiempo perdido adaptando el sistema de AGUJEROS.

   La virtud de tener Ver 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

Por lo tanto, finalmente obtuvimos un Modelo independiente que podría adaptarse a nuestras necesidades actuales (hoy necesito manejar un Juego Monouser sin reglas, mañana tengo que jugar con amigos y ahora su Multiusuario, y así sucesivamente) que no depende de cómo vamos a representarlo. Luego, un Controlador que captura las solicitudes de los usuarios provenientes de una vista, procesa los Objetos Modelo y luego devuelve la información a la Vista para representarla.

Regrese a la primera pregunta que hizo: Como puede ver (espero), MVC es una MANERA de hacer las cosas y no una TECNOLOGÍA para crear software. Podría usar sus Servlets de Java e implementar una MVC Achitecture debajo de él.

Aquí hay un Q & Un sitio de ejemplo que utiliza una arquitectura MVC para aclarar un poco

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 " The M in MVC: ¿Por qué los modelos son mal entendidos y no apreciados? ". El controlador solo debe acceder al modelo.
• Vistas : su código de GUI (presentación). Solo debe acceder al controlador
• Controlador : tu lógica. Maneja la comunicación entre el modelo y la vista.

El concepto Model-View-Controller no es nada nuevo. Comenzó con Smalltalk alrededor de 1979.

  

En su núcleo, 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 ni 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 varias maneras diferentes

Con cuidado, potencialmente puedes diseñar el modelo y el controlador para que puedas 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 incluía los conceptos de "Convención sobre la configuración", la asignación de acciones del controlador a los métodos de clase y el enrutamiento de las solicitudes de URL al código subyacente.