Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 23 vistas

    Guia 13

    Cargado por

    Manuel Gutierrez Atencio
    El documento describe los modelos de arquitectura de software MVC y MVP. MVC separa una aplicación en tres capas: modelo, vista y controlador. El modelo representa los datos, la vista genera la interfaz y el controlador maneja las interacciones. MVP es similar pero el presentador reemplaza al controlador como coordinador entre modelo y vista. Ambos modelos promueven la separación de preocupaciones y facilitan el testing.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd

    Guia 13

    Cargado por

    Manuel Gutierrez Atencio
    23 vistas3 páginas
    El documento describe los modelos de arquitectura de software MVC y MVP. MVC separa una aplicación en tres capas: modelo, vista y controlador. El modelo representa los datos, la vista genera la interfaz y el controlador maneja las interacciones. MVP es similar pero el presentador reemplaza al controlador como coordinador entre modelo y vista. Ambos modelos promueven la separación de preocupaciones y facilitan el testing.

    Título original

    GUIA 13

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    El documento describe los modelos de arquitectura de software MVC y MVP. MVC separa una aplicación en tres capas: modelo, vista y controlador. El modelo representa los datos, la vista genera la interfaz y el controlador maneja las interacciones. MVP es similar pero el presentador reemplaza al controlador como coordinador entre modelo y vista. Ambos modelos promueven la separación de preocupaciones y facilitan el testing.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    23 vistas3 páginas

    Guia 13

    Cargado por

    Manuel Gutierrez Atencio
    El documento describe los modelos de arquitectura de software MVC y MVP. MVC separa una aplicación en tres capas: modelo, vista y controlador. El modelo representa los datos, la vista genera la interfaz y el controlador maneja las interacciones. MVP es similar pero el presentador reemplaza al controlador como coordinador entre modelo y vista. Ambos modelos promueven la separación de preocupaciones y facilitan el testing.

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    Está en la página 1de 3

    EL MODELO DE DESARROLLO DE SOFTWARE

    MVC Y MVP

    Qué es el patrón MVC:


    Su nombre, MVC, parte de las iniciales de Modelo-Vista-Controlador (Model-
    View-Controller, en inglés), que son las capas o grupos de componentes en
    los que organizaremos nuestras aplicaciones bajo este paradigma.

    Es a menudo considerado también un patrón de diseño de la capa de


    presentación, pues define la forma en que se organizan los componentes de
    presentación en sistemas distribuidos. teniendo en cuenta su antigüedad, es
    obvio que ni siquiera fue ideado expresamente para sistemas web, aunque
    ahora se use mucho en ellas.

    Existen implementaciones para todo tipo de sistemas (escritorio, clientes y


    servidores web, servicios web, Single Page Applications o SPA, etc.) y
    lenguajes (Smalltalk, Java, Ruby, C++, Python, PHP, JavaScript, NodeJS,
    etc.).

    La arquitectura MVC propone, independientemente de las tecnologías o


    entornos en los que se base el sistema a desarrollar, la separación de los
    componentes de una aplicación en tres grupos (o capas) principales: el
    modelo, la vista, y el controlador, y describe cómo se relacionarán entre
    ellos para mantener una estructura organizada, limpia y con un acoplamiento
    mínimo entre las distintas capas.

    ▪ El modelo: En la capa Modelo encontraremos siempre una


    representación de los datos del dominio, es decir, aquellas entidades
    que nos servirán para almacenar información del sistema que estamos
    desarrollando. Por ejemplo, si estamos desarrollando una aplicación
    de facturación, en el modelo existirán las
    clases Factura, Cliente o Proveedor, entre otras. el Modelo será
    también el encargado de gestionar el almacenamiento y recuperación
    de datos y entidades del dominio, es decir, incluirá mecanismos de
    persistencia o será capaz de interactuar con ellos. Dado que
    habitualmente la persistencia se delega a un motor de bases de datos,
    es muy frecuente encontrar en el Modelo la implementación de
    componentes tipo DAL (Data Access Layer, o Capa de Acceso a
    Datos) y ORMs.
    • La vista: Los componentes de la Vista son los responsables de generar la
    interfaz de nuestra aplicación, es decir, de componer las pantallas, páginas,
    o cualquier tipo de resultado utilizable por el usuario o cliente del sistema. De
    hecho, suele decirse que la Vista es una representación del estado del
    Modelo en un momento concreto y en el contexto de una acción determinada.
    Por ejemplo, si un usuario está consultando una factura a través de una
    aplicación web, la Vista se encargará de representar visualmente el estado
    actual de la misma en forma de página visualizable en su navegador. Si en
    un contexto B2B el cliente de nuestro sistema es a su vez otro sistema, la
    vista podría ser un archivo XML con la información solicitada. En ambos
    casos se trataría de la misma factura, es decir, la misma entidad del Modelo,
    pero su representación es distinta en función de los requisitos.

    • El controlador: La misión principal de los componentes incluidos en el


    Controlador es actuar como intermediarios entre el usuario y el sistema.
    Serán capaces de capturar las acciones de éste sobre la Vista, como puede
    ser la pulsación de un botón o la selección de una opción de menú,
    interpretarlas y actuar en función de ellas. Por ejemplo, retornando al usuario
    una nueva vista que represente el estado actual del sistema, o invocando a
    acciones definidas en el Modelo para consultar o actualizar información.
    Realizarán también tareas de transformación de datos para hacer que los
    componentes de la Vista y el Modelo se entiendan. Así, traducirán la
    información enviada desde la interfaz, por ejemplo los valores de campos de
    un formulario recibidos mediante el protocolo HTTP, a objetos que puedan
    ser comprendidos por el Modelo, como pueden las clases o las entidades del
    dominio.

    Y de la misma forma, el Controlador tomará la información procedente del


    Modelo y la adaptará a formatos o estructuras de datos que la Vista sea
    capaz de manejar.

    Por todo ello, podríamos considerar el Controlador como un coordinador


    general del sistema, que regula la navegación y el flujo de información con
    el usuario, ejerciendo también como intermediario entre la capa de Vista y el
    Modelo.
    Qué es el patrón MVP:

    Esta arquitectura resuelve varios detalles que se presentan cuando tienes una
    aplicación con MVC. No toda la responsabilidad debe caer en
    nuestro MainActivity porque esto podría ocasionar errores de fluidez haciéndola
    crashear al haber un proceso pesado en el hilo principal de la aplicación.
    MVP organiza mejor la distribución de archivos y define las responsabilidades
    de otra forma.

    • Model: Igual que en MVC, no hay cambios acá.


    • View: Ahora el Activity/Fragment es considerado parte de la vista y
    dejamos de tenerlo en el Controller como ocurre en la arquitectura
    anterior.
    • Presenter: Es como el Controller de MVC, pero va a estar orquestando
    todo lo que sucede. Es como un mesero qué se comunicará con el
    cocinero (modelo) para traer lo que pide la vista. Debería haber un
    Presenter por cada Activity o Fragment.

    Esto hace todo mucho más limpio y facilita la realización de unit tests a la
    lógica del presenter porque no está unida a una vista específica o APIs de
    Android.

    MVP Puede ser implementado en Java SE (AWT y Swing) las aplicaciones que
    utilizan los marcos Biscotti y MVP4J.

    También podría gustarte