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

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

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.

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…)

.

¿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

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

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 View que 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 view el 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.

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)

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,

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

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

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)

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.

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.

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.

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/