Historia Del MVC

7/24/2019 Historia Del MVC

1/47

Modelo-Vista-Controlador (MVC)

Edgardo Bermdez

Pedro Martnez

Vctor Gonzlez


2/47

Modelo-Vista-Controlador

Este patrn fe descrito por primera !ez por "r#g!e $eens%ag

en &'' # la implementacin original fe realizada en *malltal%

en los la+oratorios ,ero.

MVC se +asa en la separacin de la aplicacin en tres capas

principales/ Modelo Vista # Controlador.

*e sa (0l o algna de ss !ariantes) en la gran ma#ora de las

interfaces de sario.


3/47


Modelo/ es la representacin especfica del dominio de la

informacin so+re la cal fnciona la aplicacin.

El modelo es otra forma de llamar a la capa de dominio.

1a lgica de dominio a2ade significado a los datos3 por

e4emplo calclando si 5o# es el cmplea2os del sario o

los totales impestos o portes en n carrito de la compra.


4/47


Vista/ *e presenta el modelo en n formato adecado para

interactar salmente n elemento de interfaz de sario.

Controlador/ Este responde a e!entos salmente

acciones del sario e in!oca cam+ios en el modelo #

pro+a+lemente en la !ista.


5/47


En general


6/47


Mc5as aplicaciones tilizan n mecanismo dealmacenamiento persistente (como pede ser na +ase dedatos) para almacenar los datos. MVC no mencionaespecficamente esta capa de acceso a datos por6espone 6e est encapslada por el modelo.

El o+4eti!o primordial del MVC es la retilizacin del cdigo#a implementado.

Esta tarea se facilita mc5o si a la 5ora de programartenemos la precacin de separar el cdigo en !ariaspartes 6e sean sscepti+les de ser retilizadas sinmodificaciones.


7/47


E4emplos

1os datos de na 5o4a de clclo peden mostrarse de enformato ta+lar con n grfico de +arras con no desectores.

1os datos son el modelo. *i cam+ia el modelo las !istas de+eran actalizarse en

consonancia.

El sario manipla el modelo a tra!0s de las !istas.7 (en realidad a tra!0s de los controladores)


8/47


Mas de una Vista de un Modelode Datos


9/47


MVC es tilizado con ma#or frecencia en lasaplicaciones 8e+ donde la Vista es la pgina9"M1 # el Controlador es el cdigo 6e rene la

data dinmica # genera el contenido de la pgina.

El Modelo es representado por el contenido actal6e salmente se encentra almacenado en na

+ase de datos o en arc5i!os ,M1.


10/47



11/47


Fortalezas 7 *e presenta la misma informacin de distintas formas.

7 1as !istas # comportamiento de na aplicacin de+en refle4ar

las maniplaciones de los datos de forma inmediata.

7 :e+era ser fcil cam+iar la interfaz de sario (inclso en

tiempo de e4eccin).

7 Permitir diferentes estndares de interfaz de sario o portarla

a otros entornos no de+era afectar al cdigo de la aplicacin.


12/47


En ;M1*e propone para el desarrollo del

Modelo de


13/47


Variante inicial del Patrn MVC.

Variantes del Modelo.

- Variante en la cal no eiste ningna comnicacin entre elModelo # la Vista # esta ltima reci+e los datos a mostrar a

tra!0s del Controlador.


14/47


Variante en la cal se

desarrolla na

comnicacin entre el

Modelo # la Vista donde

esta ltima al mostrar losdatos los +sca

directamente en el

Modelo dada na

indicacin del

Controladordismin#endo el con4nto

de responsa+ilidades de

este ltimo.

Variante =ntermedia del Patrn MVC.


15/47


Mc5as interfaces grficas de sario como *8ing o M?C

5acen innecesario el so de n controlador.

7 :efinen s propio fl4o de control # mane4an los e!entos

internamente.

7 =ntegran as la !ista # el controlador.

7 < esta !ariante se la sele denominar Document-View


16/47


;n controlador (controlador.4a!a por e4emplo) pede gestionar el clic en n +otn detal forma 6e recoge datos por medio del Modelo (model.cargar@teto(..)) # losmanda a la Vista (el applet) para s actalizacin (!ista.mostrar@teto( ))/

A

$esponde al clic% en +otn a+rir 1a respesta al e!ento es 5acer 6e se a+ra en la !ista

el arc5i!o correspondiente a la referencia seleccionada en el com+o +oA

!oid +@a+rir@actionPerformed(+tener teto de arc5i!o

A *i la carga de arc5i!o es o% lo mestro. *i no a!iso de error A

if (teto@arc5i!o F nll) D

vista.mostrar@teto(teto@arc5i!o)3 AA Mostrar teto

vista.mostrar@a!iso(Carga de H pat5 H completada.)3I

else

vista.mostrar@a!iso(Error en la carga de H pat5)3

I


17/47

P$>,J


18/47

Pro#

Propsito

Proporciona n sstitto de otro o+4eto con el

fin de controlar s acceso.

Moti!acin

$azn para controlar el acceso a n o+4eto/

:iferir el coste de s creacin e inicializacin5asta 6e el o+4eto realmente se necesite.


19/47

Pro#

E4emplo

Editor de docmentos 6e permite o+4etos

grficos a+rir n docmento de+era ser

rpido realmente no todos los o+4etos son

!isi+les a la !ez

*olcinCrear los o+4etos K+a4o demandaL


20/47

Pro#

*olcin

;sar n o+4eto 6e sstit#a a la imagen real

(P$>,J). El pro# acta como si fese la imagen # la instancia

cando es necesario.


21/47

Pro#

*olcin

1a imagen est gardada en arc5i!osseparados # el Pro# garda el nom+re

del arc5i!o como la referencia al o+4eto

real. El Pro# tam+i0n garda el tama2o.


22/47

Pro#


23/47

Pro#

El editor de docmento accede a la imagen a

tra!0s de la interfaz definida por la clase

a+stracta Grap5ic

=magePro# es na clase para las imgenes6e es creada por demanda contiene el

nom+re del arc5i!o como na referencia a la

imagen en el disco

El nom+re del arc5i!o es pasado como

argmento al constrctor de =magePro# .


24/47

Pro#

=magePro# tam+i0n garda el tama2o de laimagen # na referencia a la instancia real.Esta referencia no ser !alida 5asta 6e elPro# instancie la imagen real.

1a operacin :ra8 se asegra 6e la imagenesta instanciada antes de responder lasolicitd.

GetEtent reen!a la solicitd a la imagen

solo si #a fe instanciada de lo contrario=magePro# de!el!e el tama2o 6e tienegardado.


25/47

Pro#


26/47

Pro#

Pro# de proteccin

Controla el acceso al o+4eto original. Es til si el o+4eto

original tiene diferentes derec5os de acceso.

$eferencia elegante (smart pointers)

$ealiza acciones adicionales cando se acceden a los

elementos referenciados


27/47

Pro#

Estrctra


28/47

Pro#

:iagrama de *ecencia


29/47

Pro#

Participantes

Pro#

Mantiene n referencia al o+4eto real

Mantiene n mismo interfaz 6e el o+4eto

real

Mantiene el acceso al o+4eto realCodificacin de peticiones Cac5ing de

informacin compro+ar permisos


30/47

Pro#

Participantes

*+4ect

:efine el interfaz comn a Pro# #

$eal*+4ect

$eal*+4ect:efine el o+4eto real 6e representa el Pro#


31/47

Pro#

Consecencias

El pro# introdce n ni!el de indireccin

cando accede a n o+4eto. 1a indireccin

tiene mc5os sos dependiendo del tipo de

pro#/

$emoto/ ocltar espacio de memoria.

Virtal/ optimizaciones creando o+4etos +a4odemanda

Proteccin/ tareas adicionales.


32/47

Pro#

$elacionados

*i ofrece n interfaz distinto (pro# de

segridad)


33/47

P$>,JAB$>E$


34/47

Pro#ABro%er

Propsito

Estrctrar sistemas distri+idos en los

cales srge la necesidad de na iteracin

remota entre componentes.

Moti!acin

:esacoplar la interaccin de los sarios en

los clientes # ser!idores.


35/47

Pro#ABro%er

E4emplo

En el desarrollo de n KMercado Ne+L

tenemos desarrollados dos agentes elcomprador # el !endedor. Pero estos estn

desarrollados en plataformas diferentes 6e

no permite 6e tengan comnicacin.


36/47

Pro#ABro%er

*olcin

Cando n cliente necesita comprar n

prodcto solicita a tra!0s de n Pro# alagente Bro%er los !endedores 6e tieneregistrado. El Bro%er se comnica por nPro# con el ser!idor para lle!ar a ca+o la

peticin.


37/47

Pro#ABro%er

*olcin

El agente Bro%er entrega la informacin

necesaria a el pro#-cliente # al pro#-

ser!idor para 6e estos esta+lezcan na

comnicacin efecti!a 6e permita realizar

la operacin.


38/47

Pro#ABro%er

1os +ro%er permiten realizar coneiones

entre clientes # ser!idores de diferentes

plataformas.

1e entregan la informacin necesaria a los

Pro# para 6e estos realicen las

coneiones.


39/47

Pro#ABro%er

>tro e4emplo

El +ro%er sir!e de intermediario

entre el comprador # el!endedor.

Permitiendo 6e logren

conectarse # realizar la

transaccin.


40/47

Pro#ABro%er

1os patrones Pro#ABro%er se peden

implementar de diferentes maneras esto

depende de los re6erimientos de los

sistemas.

;na ?orma de implementarlos es permitiendo

6e los Pro# cliente # ser!idor se comni6en

entre ellos cando es posi+le.


41/47

Pro#ABro%er


42/47

Pro#ABro%er

:iagrama de *ecencia


43/47

Pro#ABro%er

>tra manera m# sada es no permitir 6e los

Pro# cliente # ser!idor se comni6en.

Esta restriccin podra ser necesaria por polticas de

segridad de los ser!idores.

"am+i0n por mantener n orden # control de todo lo

6e pasa por los Pro#s.


44/47

Pro#ABro%er


45/47

Pro#ABro%er


46/47

Pro#ABro%er

Consecencias


47/47

Pro#ABro%er

E4emplos

Este patrn es m# sado por sistemas con

estndar COR!(1E O.

Norld Nide Ne+

Historia Del MVC

Documents

Transcript of Historia Del MVC