En esta clase vamos a ver el tema conceptual que hay detrás del MDC.
El modelo vista controlador, pero primero vamos a partir por Spring MVC.
Qué es y qué tiene que ver Spring MVC con Spring Framework?
Es lo mismo.
Bueno, y por supuesto que no es Spring.
Es parte, es un componente del ecosistema de Spring Framework.
Solamente una parte, porque también dentro de Spring Framework tenemos todo lo que a inyección de dependencias,
que si bien se integra con Spring MS es un componente que es parte del core.
También tenemos todo lo que es integración con o R.M.
Trabajar con base datos mediante JDBC.
Todo lo que es programación orientada a aspectos.
En fin, hay un montón de cosas webs, socket, spring security, en fin, y mucho más.
Pero bien, centrémonos en Spring.
MS Es un framework web, un componente parte de Spring Frenkel.
Por supuesto que está basado en la arquitectura modelo vista controlador y toma como ventajas.
Incluye los siguientes principios de partida Bueno LMS separación de capas modelo por un lado, la vista
por otro y el controlador, pero además se integra con el contexto de inyección de dependencias.
Eso también lo vamos a ver en el curso próximamente.
Orientado al uso de interfaces.
Está muy conectado con inyección de dependencia porque podemos inyectar un componente a través de su
interfaz y no a través de su tipo concreto.
La idea es desacoplar la implementación concreta y utilizar tipos más abstractos en el día mañana.
Nuestra implementación, nuestra clase concreta que estemos utilizando, por ejemplo, de un acceso
a datos podría cambiar y eso implica tener que modificar todas las clases y código donde se está utilizando,
mientras con interfaces es mucho más genérico, mucho más abstracto y solamente implementamos una nueva
clase de esa interfaz.
Pero ese tipo abstracto se mantiene.
Pero bueno, cosas que vamos a ver después.
Uso de clases POJO clases simple de Java con atributos y métodos Kether y Z.
Desacoplar completamente de los framework no implementa ninguna interfaz o clases de framework o de
API y son muy reutilizables.
Representan los datos de nuestra aplicación.
Típicamente lo utilizamos con JPA cuando mapeados a las tablas.
Después vamos a ver que la clase Identity que están mapeados a tablas de la base datos son clases de
internet de JPA.
Finalmente son POJO.
Son clases simple de Java con atributos y sus jeeter y Z, cosa que después vamos a ver por ahora LMS
mucho más allá.
Un patrón de diseño es un patrón de arquitectura, ya que internamente engloba a varios patrones de
diseño, es decir, está formado por varios patrones.
No solamente uno es un patrón de arquitectura, es una parte importante de un framework web.
Separa nuestra aplicación en tres grandes component.
Por un lado tenemos el controlador, tenemos la vista y el modelo.
El usuario a través de una Gabor interactúa directamente con el controlador enviando solicitudes peticiones
http.
Por lo tanto, hay una comunicación entre el navegador el cliente con el controlador.
El controlador va a recibir estas peticiones de usuarios, la va a manejar.
Por ejemplo, si el usuario le envía un Heidy, un dato va a tomar Estadi y va a ir a buscar un registro
a la base.
Dato El cliente está solicitando un dato, un registro mediante un Heidy controlador interactúa con
el modelo.
Entonces el modelo ya se encarga de trabajar con los datos, ya sea consultas, operaciones, select,
actualizaciones con INSER, con APDAYC, con Delight, ID, en fin.
Y todo esto lo hace a través de otros componentes, clases como el acceso a datos o los datos o repository
clase servis que agrupan varios datos, manejan transacciones.
En fin, el modelo se refiere a la lógica de negocio, a los datos de nuestra aplicación.
Estos datos regresan al controlador, el controlador se lo pasa a la vista y la vista es la que se encarga
de renderizar, de mostrar los datos del modelo y por eso acá tenemos estas relaciones.
El controlador obtiene datos de la lógica de negocio, el modelo y se lo pasa a la vista.
Renderiza estos datos en la vista.
Por lo tanto, la vista ya tiene acceso a este objeto del modelo.
Por ejemplo, con sus atributos getter y setters y puede mostrar estos datos del modelo.
Si trabajamos con hiberna con JPA cosas que vamos a ver, el modelo básicamente sería nuestras clases
ENTITY, que también son pujos con atributos, métodos, grilletes.
Por lo tanto, la vista puede mostrar los datos de esta clase Entity.
Y una vista no solamente puede mostrarse, sino que también puede enviar datos al controlador.
Por ejemplo, una vista que es un formulario.
Ahí tenemos el proceso inverso que iría desde la vista.
Al controlador hacemos un submit.
Una petición HTTP del tipo post, como por ejemplo el usuario carga un formulario, hace una solicitud,
el controlador la recibe, muestra el formulario y después con un clic en el botón Enviar se envía el
formulario, pero del tipo post lo recibe.
El controlador obtiene los datos del formulario.
Estos datos se van a poblar dentro del objeto del modelo y si persisten o se actualizan enlaces.
Por lo tanto, el modelo constantemente está interactuando y está mapeado a tablas.
Enlace atto.
Cómo funciona spring m%s.
Bueno, primero existe un front controller.
Es un patrón de diseño que está dentro de spring mבs.
Este componente.
Este patrón se encarga de recibir estas solicitudes.
HTTP del cliente del usuario obtiene esta ruta VL.
Recordemos que los controladores están mapeados a rutas jureles.
Obtiene esta ruta.
Iba a buscar el controlador que corresponde a esta ruta y le asigna el request a este controlar para
obtener los datos los parámetros que se están enviando.
Recordemos que esta ruta se mapear con Rico es mapping con Quiet Mapping o Post Mapping, dependiendo
el verbo o tipo de la petición http.
El método el controlador también interactúa.
Se relaciona con la lógica negocio clase servis o de acceso dato y por ejemplo, obtiene estos datos
a través de una consulta y se lo envía a la vista.
Le pasa estos datos a la vista para que muestre estos datos del modelo a la vista.
Y cómo se lo pasa?
Bueno, eso ya lo vimos utilizando el model Model and view, el map de Yaba, el Model Map, en fin,
el controlador retorna o asigna el nombre lógico de la vista que va a mostrar.
Eso también lo vimos.
Recordemos que el método Handler retorna un string.
En ese string indicamos el nombre la vista de forma interna, porque esto no se ve en el framework,
lo maneja de forma implícita, pero hay un view resolver un manejador que resuelve la vista por defecto.
La vista es HTML si estamos trabajando con Tinduf, pero también podemos configurar para que nuestra
vista también sea del tipo PDF o un Excel o cualquier otro tipo, un archivo plano o lo que sea, también
lo veremos más adelante.
Finalmente, la vista mostrada al cliente usando los datos del objeto model bien una característica
en la clara separación de funciones dentro de MS.
Por un lado, tenemos los controladores que se encargan de ciertas tareas.
Por otro lado tenemos los validad ores que se encargan de validar el formulario, los datos que recibe
el controlador.
Por otro lado, tenemos el objeto de formulario que está mapeado también a la lógica de negocio.
Es bidireccional.
Por lo general, el objeto de formulario, que también se le conoce como objeto de comando, está mapeado
tanto a la tabla de la base dato como también a los campos del formulario.
Luego tenemos el despachen cerle nuestro fueron controles que es el encargado como vimos de seleccionar
el controlador y su método handler según la ruta U rl los Handler Mapping es la ruta de mapeo que tiene
cada método de acción del controlador.
Lo podemos configurar o mapear con la anotación Request Mapping o Get Mapping o Post Mapping.
También tenemos los View Resolver que se encarga de resolver la vista a cargar, ya sea por el nombre
y también el tipo de vistas.
Si queremos renderizar un HTML común y corriente con left o un PDF, un Excel, un archivo plano, un
Jason, en fin, entonces cada uno de estos componentes de estas partes de Spring mבs llevan a cabo
diferentes tareas y cada tarea muy específica en cada uno de estos y pueden ser reemplazables sin afectar
a los demás componentes.
Y para finalizar lo que hace un controlador.
Ya hemos mencionado que se encarga de manejar las solicitudes de los usuarios, pero además proporcionan
acceso a la lógica de negocio.
Delegas la lógica de negocio a un conjunto de clases de servicio.
Los servicios.
Estas clases servis a su vez tienen acceso a la base de datos mediante los datos o repository.
La interfaz de acceso a datos los controladores reside en parámetros de los usuarios.
Los input a través de formulario o parámetros de la ruta Vll y los convierten en un objeto del modelo
poblando en sus atributos estos datos enviados y después los datos se pueden actualizar o persistir
en nuestra base.
Me despido y nos vemos en la próxima clase.