Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Modelo vista controlador vas Programacion por n capas

4,094 views

Published on

Hoy en día las aplicaciones informáticas centran su atención en dos aspectos fundamentales: cómo lograr construir mejores aplicaciones en menos tiempo, y cómo utilizar mayor cantidad de estándares en el diseño de las aplicaciones que permitan mayor reutilización del código y mejores mantenimientos a los sistemas desarrollados.
La realización de Sistemas de información se ha venido desarrollando en base a técnicas de programación, principalmente; la programación estructurada, luego en combinación utilizando la programación por eventos, actualmente se pudiera decir que se ha llegado a una madurez con la potencialidad de la programación orientada a objetos por la ventaja en la reutilización de código. En adición a ellas, se cuenta actualmente con la programación en n capas que hace uso de la programación orientada a objetos; la cual consiste en separar el código fuente según sea el rol, responsabilidad y funcionalidad; por ende el desarrollo es más rápido, y resulta más fácil el darle mantenimiento al sistema.
En este trabajo se hablara de igual manera sobre el patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la organización independiente del Modelo, la Vista y el Controlador.
De esta forma, dividimos el sistema en tres capas donde, como explicare más adelante, tenemos la encapsulación de los datos, la interfaz o vista por otro y por último la lógica interna o controlador.
Para todo tipo de sistemas y de tecnologías (Java, Ruby, Python, Perl, Flex, SmallTalk, .Net…)

Published in: Software
  • Be the first to comment

Modelo vista controlador vas Programacion por n capas

  1. 1. Instituto Tecnológico Superior de Calkini en el Estado de Campeche Alumno: Rodolfo Alejandro Uhu Colli Matricula: 4266 Carrera: Ingeniería en Sistemas Computacionales Profesor: Eduardo Moreno Caballero Asignatura: Tópicos de Programación Móvil Ciclo Escolar 20162017N
  2. 2. Objetivo. Describir el Modelo Vista, Controlador y la Programación por n capas, para hacer una comparación de cada uno de estos modelos, conociendo sus características y así determinar qué modelo es mejor de cierta manera
  3. 3. Procedimiento. 1.- Para empezar a realizar el trabajo documental lo primero fue buscar información en diferentes fuentes de información ya sea en internet o en libros. 2.- Revise diferentes páginas, algunos artículos y libros para buscar información. 3.- De todo lo que encontré lo guardaba para luego usarlo. 4.- Después de investigar abrí la rúbrica para seguir el formato establecido. 5.- Formule el objetivo de la investigación. 6.- Lo siguiente fue leer lo investigado. 7.- Después de leer lo investigado, formule la pregunta de investigación. 8.- Lo siguiente fue resumir la información resaltando las partes importantes para anexar como contenido a la investigación. 9.- luego de haber resumido la información investigada, lo siguientes fue acomodar la información de acuerdo a la rúbrica establecida. 10.- Para casi terminar revise el documento hecho para quitar las faltas que presentaba y darle el formato que pedía la rúbrica de evaluación. 11.- Al final solo saque mis conclusiones y anexe las fuentes bibliográficas.
  4. 4. Introducción. Hoy en día las aplicaciones informáticas centran su atención en dos aspectos fundamentales: cómo lograr construir mejores aplicaciones en menos tiempo, y cómo utilizar mayor cantidad de estándares en el diseño de las aplicaciones que permitan mayor reutilización del código y mejores mantenimientos a los sistemas desarrollados. La realización de Sistemas de información se ha venido desarrollando en base a técnicas de programación, principalmente; la programación estructurada, luego en combinación utilizando la programación por eventos, actualmente se pudiera decir que se ha llegado a una madurez con la potencialidad de la programación orientada a objetos por la ventaja en la reutilización de código. En adición a ellas, se cuenta actualmente con la programación en n capas que hace uso de la programación orientada a objetos; la cual consiste en separar el código fuente según sea el rol, responsabilidad y funcionalidad; por ende el desarrollo es más rápido, y resulta más fácil el darle mantenimiento al sistema. En este trabajo se hablara de igual manera sobre el patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la organización independiente del Modelo, la Vista y el Controlador. De esta forma, dividimos el sistema en tres capas donde, como explicare más adelante, tenemos la encapsulación de los datos, la interfaz o vista por otro y por último la lógica interna o controlador. Para todo tipo de sistemas y de tecnologías (Java, Ruby, Python, Perl, Flex, SmallTalk, .Net…) .
  5. 5. ¿Cuál es la finalidad de cada uno de estos modelos y cómo determinar cuál es el mejor modelo a implementar? Modelo Vista – Controlador MVC El Modelo-Vista-Controlador, es considerado un patrón que se originó en la comunidad Smalltalk para implementar interfaces de usuario en los que las responsabilidades están bien distribuidas entre los componentes del diseño. o Modelo Representa la lógica de negocio de la aplicación, es decir, representa objetos y sus interacciones del mundo real. Encapsula el modelo de una aplicación en componentes facilita la depuración, mejora la calidad y favorece la reutilización de código. Se refiere también a las clases que conforman el aplicativo, y por ende a la información con la cual el sistema opera;  Contiene el núcleo de la funcionalidad (dominio) de la aplicación.  Encapsula el estado de la aplicación.  No sabe nada / independiente del Controlador y la Vista. o Controlador El controlador es responsable de recibir los eventos, determinar el procesador del evento, invocar al procesador y finalmente provocar la generación de la vista apropiada. Responde a eventos o peticiones del usuario, e invoca cambios en el modelo y muy seguramente en la vista. Es la capa central, ya que cuando
  6. 6. desarrollamos con Visual Studio utilizando Web From, llamamos a las vistas como el punto de partida del aplicativo, con el modelo MVC el centro es el controlador, ya que al ingresar una URL (Localizador Único de Registro o dirección web), el usuario no hace referencia a una vista, sino a un controlador, quien a través de un evento o método llama o muestra la vista indicada.  Reacciona a la petición del Cliente, ejecutando la acción adecuada y creando el modelo pertinente o Vistas Las vistas son las porciones de la aplicación que presentan salida al usuario. Como parte de la generación la vista debe presentar al usuario el conjunto de eventos que puede generar en ese momento concreto. Separar el modelo y la vista permite la construcción de interfaces con diferentes apariencias.  Es la presentación del Modelo.  Puede acceder al Modelo pero nunca cambiar su estado.  Puede ser notificada cuando hay un cambio de estado en el Modelo Para entender cómo funciona nuestro patrón Modelo vista controlador, se debe entender la división a través del conjunto de estos tres elementos y como estos componentes se comunican unos con los otros y con otras vistas y controladores externos al modelo principal. Para ello, es importante saber que el controlador interpreta las entradas del usuario (tanto teclado como el ratón), enviado el mensaje de acción al modelo y a la vista para que se proceda con los cambios que se consideren adecuados  Comunicación El modelo, la vista y el controlador deben comunicarse de una manera estable los unos con los otros, de manera que sea coherente con las iteraciones que el usuario realizara. Como es lógico la comunicación entre la vista y el controlador es bastante básica pues están diseñados para operar juntos, pero los modelos se comunican de una manera diferente, un poco más sutil
  7. 7.  Modelo pasivo No es necesario para el modelo tener alguna disposición a él, simplemente basta con tener en cuenta su existencia. El modelo no tiene ninguna responsabilidad para comunicar los cambios a la vista porque ocurren solo por orden del usuario, por lo que esta función la llevara a cabo el controlador porque será el que interprete las ordenes de este usuario debido a que solo debe comunicar que algo ha cambiado. Por esto, el modelo es se encuentra en modo inconsciente y su participación en este caso es irrisoria.  Unión del modelo con la vista y el controlador Como no todos los modelos pueden ser pasivos, necesitamos algo que comunique al controlador y a la vista, por lo que en este caso, si que necesitamos el modelo, ya que solo este puede llevar a cabo los cambios necesarios al estado actual en el que estos se encuentran. Al contrario que el modelo, que puede ser asociado a múltiples asociaciones con otras vistas y controladores, cada vista solo puede ser asociada a un único controlador, por lo que han de tener una variable de tipo controler que notificara a la vista cuál es su controlador o modelo asignado. De igual manera, el controlador tiene una variable llamada Viewque apunta a la vista. De esta manera, pueden enviarse mensajes directos el uno al otro y al mismo tiempo, a su modelo. Al final, la vista es quien lleva la responsabilidad de establecer la comunicación entre los elementos de nuestro patrón MVC. Cuando la vista recibe un mensaje que concierne al modelo o al controlador, lo deja registrado como el modelo con el cual se comunicara y apunta con la variable controller al controlador asignado, enviándole al mismo su identificación para que el controlador establezca en su variable viewel identificador de la vista y así puedan operar conjuntamente. El responsable de deshacer estas conexiones, seguirá siendo la vista, quitándose a sí misma como dependiente del modelo y liberando al controlador.
  8. 8.  Fortalezas  Se presenta la misma información de distintas formas.  Las vistas y comportamiento de una aplicación deben reflejar las manipulaciones de los datos de forma inmediata.  Debería ser fácil cambiar la interfaz de usuario (incluso en tiempo de ejecución).  Permitir diferentes estándares de interfaz de usuario o portarla a otros entornos no debería afectar al código de la aplicación.  Qué Ventajas trae utilizar el MVC?  Es posible tener diferentes vistas para un mismo modelo (eg. representación de un conjunto de datos como una tabla o como un diagrama de barras).  Es posible construir nuevas vistas sin necesidad de modificar el modelo subyacente.  Proporciona un mecanismo de configuración a componentes complejos muchos más tratable que el puramente basado en eventos (el modelo puede verse como una representación estructurada del estado de la interacción).  ¿Cuáles son los orígenes del Modelo Vista Controlador? Basado en información histórica, puede decirse que este fue descrito por primera vez en 1979 por Trygve Reenskaug, trabajador de Smalltalk, en unos laboratorios de gran investigación de Xerox.  Flujo que sigue el control en una implementación general de un MVC Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente:  El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace)
  9. 9.  El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.  El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.  El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra  La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente. Programación por “n” de Capas La programación por capas es una arquitectura cliente-servidor en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado. Un buen ejemplo de este método de programación sería el modelo de interconexión de sistemas abiertos. Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles,
  10. 10. de forma que basta con conocer la API que existe entre niveles. En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten). El diseño más utilizado actualmente es el diseño en tres niveles (o en tres capas). Capas y niveles 1. Capa de presentación: es la que ve el usuario (también se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio. 2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina
  11. 11. capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación. 3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. Todas estas capas pueden residir en un único computador, si bien lo más usual es que haya una multitud de computadoras en donde reside la capa de presentación (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo computador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o más computadoras. Así, si el tamaño o complejidad de la base de datos aumenta, se puede separar en varias computadoras los cuales recibirán las peticiones del computador en que resida la capa de negocio. Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separación, esta capa de negocio podría residir en uno o más computadores que realizarían solicitudes a una única base de datos. En sistemas muy complejos se llega a tener una serie de computadores sobre los cuales corre la capa de negocio, y otra serie de computadores sobre los cuales corre la base de datos. Diferencia entre capas y niveles En una arquitectura de tres niveles, los términos "capas" y "niveles" no significan lo mismo ni son similares. El término "capa" hace referencia a la forma como una solución es segmentada
  12. 12. desde el punto de vista lógico. Por ejemplo: 1. Presentación. 2. Lógica de Negocio. 3. Datos. En cambio, el término "nivel" corresponde a la forma en que las capas lógicas se encuentran distribuidas de forma física. Por ejemplo: A. Una solución de tres capas (presentación, lógica del negocio, datos) que residen en una solo computadora (Presentación + lógica + datos). Se dice que la arquitectura de la solución es de tres capas y un nivel. B. Una solución de tres capas (presentación, lógica del negocio, datos) que residen en dos computadores (presentación+ lógica por un lado; lógica + datos por el otro lado). Se dice que la arquitectura de la solución es de tres capas y dos niveles.  Ventajas del modelo  Desarrollos paralelos (en cada capa)  Aplicaciones más robustas debido al encapsulamiento  Mantenimiento y soporte más sencillo (es más sencillo cambiar un componente que modificar una aplicación monolítica)  Mayor flexibilidad (se pueden añadir nuevos módulos para dotar al sistema de nueva funcionalidad)
  13. 13.  Alta escalabilidad La principal ventaja de una aplicación distribuida bien diseñada es su buen escalado, es decir, que puede manejar muchas peticiones con el mismo rendimiento simplemente añadiendo más hardware. El crecimiento es casi lineal y no es necesario añadir más código para conseguir esta escalabilidad. Como tecnología, las arquitecturas de n-capas proporcionan una gran cantidad de beneficios para las empresas que necesitan soluciones flexibles y fiables para resolver complejos problemas inmersos en cambios constantes. --- ---Comparación de los Modelos.----- Como podrá observar el en la Capa Común o de Objetos del modelo a N Capas, tendremos nuestro Modelo del Dominio (los diagramas de clases), que para el modelo MVC, están en la Capad Modelo. La Capa de Lógica o RN (Reglas del Negocio), del modelo a N Capas contiene la validación de los datos a la luz de las RN. Para el modelo MVC, estas se encuentran en la Capa del Controlador.
  14. 14. La Capa de Acceso a Datos del modelo N Capas, es la que posee el ORM; el cual estará en la Capa Modelo, junto a la información del aplicativo (las clases) en el modelo MVC. La Capa de Vista, juega el mismo papel en ambos modelos, es decir, proporcionar al usuario la interacción con el aplicativo.
  15. 15. Conclusión. Para concluir podemos decir que por un lado, MVC es un patrón arquitectural; define en qué bloques (o capas) estructuramos lógicamente nuestra aplicación (Modelo, Vista y Controlador), pero además detalla las responsabilidades exactas de cada capa y la forma que tienen de relacionarse entre sí. Por tanto, si programas de acuerdo al patrón MVC estarás dividiendo tu sistema en tres capas, pero no al contrario: puedes programar en 3 capas sin necesidad de seguir dicho patrón. Por otro lado, el estilo de programación de n capas se basa en segmentar un proyecto o trabajo en varias partes para realizar una programación independiente en cada una de ellas, facilita la reutilización de capas, ayuda mucho al programador de aplicaciones para dar mantenimiento al sistema, dado que el problema que pudiera darse es visto en la capa respectiva.
  16. 16. Referencias. 1. “Modelo Vista Controlador”, disponible en: http://www.neleste.com/modelo-vista- controlador/ 2. Catalani, Exequiel.: “Arquitectura Modelo/Vista/Controlador”, disponible en: http://exequielc.wordpress.com/2007/08/20/arquitectura-modelovistacontrolador/. 3. “Patrón Modelo-Vista-Controlador“, disponible en: Http://www.proactiva-calidad.com/java/patrones/mvc.html 4. Figueroa, José.: “Introducción al Modelo MVC y de N Capas“, disponible en: http://albeverry.blogspot.mx/. 5. “Modelo Vista Controlador“, disponible en: http://es.wikipedia.org/wiki/Modelo_Vista_Controlador 6. “Lógica de Negocio“, disponible en http://es.wikipedia.org/wiki/L%C3%B3gica_de_negocio 7. “Framework“, disponible en http://es.wikipedia.org/wiki/Framework“ 8. Introducción a MVC con PHP, Primera Parte“¨, disponible en http://www.jourmoly.com.ar/introduccion-a-mvc-con-php-primera-parte/

×