Modelo vista controlador vas Programacion por n capas

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 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.

 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/

Modelo vista controlador vas Programacion por n capas

Más contenido relacionado

La actualidad más candente (20)

Similar a Modelo vista controlador vas Programacion por n capas (20)

Último (10)

Modelo vista controlador vas Programacion por n capas