Sobre la traducción de la literatura inglesa de mvc
Descubre la ubicación de las tres partes de MVC en la arquitectura J2EE.
La relación correspondiente entre la arquitectura MVC y J2EE es que la vista está en la capa web o capa de cliente, generalmente JSP/Servlet, que es la parte de visualización de la página. El controlador también está en la capa web, generalmente implementado a través de Servlet, que es la parte lógica de la visualización de la página. El modelo está ubicado en la capa intermedia y generalmente se implementa en el lado del servidor mediante javaBean o EJB.
Te lo explicamos detalladamente a continuación.
Capa de vista (vista):
La vista representa la interfaz de interacción del usuario, que se puede resumir como la interfaz HTML de una aplicación web, pero también puede ser XHTML, XML o Applete. A medida que las aplicaciones crecen en complejidad y tamaño, el manejo de interfaces se vuelve cada vez más desafiante. Una aplicación puede tener muchas vistas diferentes. El patrón de diseño MVC se limita a la recopilación y el procesamiento de datos y solicitudes de los usuarios en las vistas, y no incluye el procesamiento de procesos comerciales en las vistas. El procesamiento del proceso de negocio se deja en manos del modelo. Por ejemplo, la vista de la orden solo acepta datos del modelo y los muestra al usuario, y transfiere datos de entrada y solicitudes desde la interfaz de usuario a los controles y al modelo.
Capa de modelo (modelo):
Modelo: Es el procesamiento de procesos/estados de negocio y la formulación de reglas de negocio. El flujo del proceso de negocio es una operación de caja negra en otras capas. El modelo acepta los datos solicitados por la vista y devuelve el resultado final del procesamiento. Se puede decir que el diseño del modelo de negocio es el núcleo más importante de MVC. El modelo EJB actualmente popular es un ejemplo de aplicación típico. Además, divide el modelo desde la perspectiva de la implementación de la tecnología de aplicaciones para hacer un uso completo de los componentes existentes, pero no puede usarse como marco para los modelos de diseño de aplicaciones. Simplemente le indica que puede utilizar algunos componentes técnicos basados en el diseño de este modelo, reduciendo así la dificultad técnica. Para un desarrollador, puede centrarse en el diseño de modelos de negocio. El patrón de diseño MVC nos dice que es muy importante extraer el modelo de aplicación de acuerdo con ciertas reglas. Esta es también la base de diseño para juzgar si un desarrollador es excelente. La abstracción y la concreción no pueden estar ni demasiado lejos ni demasiado cerca. MVC no proporciona un método de diseño para modelos, solo le dice que estos modelos deben organizarse y administrarse para facilitar la reconstrucción del modelo y mejorar la reutilización. Podemos utilizar la programación de objetos como analogía. MVC define una clase de nivel superior y le dice a sus subclases que solo puede hacer esto, pero no hay forma de restringirlo. Esto es muy importante para los desarrolladores de programación. Hay otro modelo muy importante en el modelo de negocio que es el modelo de datos. El modelo de datos se refiere principalmente al almacenamiento de datos (persistencia) de objetos de entidad. Por ejemplo, guarde el pedido en la base de datos y obtenga el pedido de la base de datos. Podemos enumerar este modelo por separado y todas las operaciones relacionadas con la base de datos se limitan a este modelo.
Capa de control (controlador):
Se puede entender que el controlador recibe la solicitud del usuario, hace coincidir el modelo con la vista y satisface la solicitud del usuario. El papel de dividir la capa de control también es muy obvio. Le dice claramente a usted, como distribuidor, qué tipo de modelo elegir, qué tipo de vista elegir y qué tipo de solicitud de usuario completar. La capa de control no realiza ningún procesamiento de datos. Por ejemplo, cuando un usuario hace clic en una conexión, la capa de control no procesa la información comercial después de aceptar la solicitud. Simplemente pasa la información del usuario al modelo, le dice al modelo qué hacer y selecciona una vista que cumpla con los requisitos para regresar al usuario. Por lo tanto, un modelo puede corresponder a múltiples vistas y una vista puede corresponder a múltiples modelos.
La separación de modelo, vista y controlador permite que un modelo tenga múltiples vistas de visualización. Si el usuario cambia los datos del modelo a través del controlador de una vista, todas las demás vistas que dependen de esos datos deben reflejar esos cambios. Por lo tanto, cada vez que cambie algún dato, el controlador notificará a todas las vistas del cambio, lo que hará que la pantalla se actualice. En realidad, este es un mecanismo modelo de propagación de cambios.