• Embed Doc
  • Readcast
  • Collections
  • CommentGo Back
Download
 
MODELO VISTA CONTROLADOR (MVC)1.ORIGENES DEL MVC (MODELO VIST A CONTROLADOR)El modelo vista controlador fue descrito por primera vez en 1979 por Trygve Reenskaug trabajador de Smalltalk en laboratorios deinvestigación de Xerox.El Modelo-Vista-Controlador se creó para Smalltalk a finales de lossetenta. A partir de entonces su uso se ha ido extendiendo cada día máspara la construcción de sistemas software con interfaz gráfica. Suenorme uso ha provocado que haya también multitud de referencias alpatrón Modelo-Vista-Controlador, que en muchas ocasiones son fuentesde confusión porque se utilizan distintos contextos de aplicación para elpatrón, se tratan de conseguir objetivos distintos, los nombres de loscomponentes del patn son los mismos pero con diferentesresponsabilidades, los diagramas de clases y de secuencia son tambiéndiferentes. Además, hay referencias donde se dan ejemplos deimplementación del patrón con sus particularidades, ya que la mayoríade los entornos de desarrollo de aplicaciones, sobre todo deaplicaciones web, dan “facilidades” para implementar el patrón Modelo-Vista-Controlador. A veces esto no es del todo bueno, ya que realmenteno implementan de forma correcta la esencia del patrón y confunden aúnmás al lector, que utiliza estas implementaciones como ejemplo paraaprender a usar el patrón Modelo-Vista-Controlador.[1]MVC fue propuesto como una muy buena solución para el desarrollo enSmalltalk de interfaces gráficas en entornos de ventanas. Cada ventanaestaba compuesta de una triada MVC. La vista se encargaba deldibujado de mapas de bits, el controlador atendía acciones del mouse yteclado, y el modelo guardaba el estado de la ventana y la informaciónmostrada en ella. Cada vista esta asociada con un controlador y unmodelo en su creación. Cualquier modelo podía ser asociado débilmentea cualquier vista, pero cada par controlador/vista siempre se manteníanasociados con su respectiva pareja. En realidad el controlador no seencargaba de manejar la gica del negocio en la aplicación, supropósito era manejar la interacción del mouse y el teclado, y actualizar la vista acorde, lo cual no era una tarea trivial. El modelo podía ser compartido entre diferentes displays, por eso la necesidad de se
 
débilmente asociable, una necesidad que aún hoy persiste, pero no asípara la asociación modelo/vista, ésta tenía un propósito diferente: elmodelo debía poder notificar a las vistas asociadas sobre cambios queocurrieran fuera de su entorno. [2]
Smalltalk: Sistema informático que permite realizar tareas decomputación mediante la interacción con un entorno de objetos virtuales.
Trygve Reenskaug: (nacido en 1930) es un científico de la computaciónnoruego. Formuló el modelo-vista-controlador de patrón de diseño desoftware para el GUI en 1979 durante su visita a Xerox Parc.Por su propia admisión, "La parte más difícil fue a golpear a los nombresde las buenas para los diferentes componentes arquitectónicos. Modelo-Vista-editor fue el primer set."Él ha participado ampliamente en la investigación de métodos orientadosa objetos y desarrollado la funcn de modelado OOram todo yherramienta en 1983. Fundó la empresa en 1986 que Taskonherramientas desarrolladas sobre la base de la OORam método.Reenskaug escribel libro de trabajo con objetos: El todo deIngeniería de Software OOram con co-autores P. Wold y O. A. Lehne.Más tarde trabajó con el desarrollo de UML. Actualmente [update] esprofesor emérito de la informática en la Universidad de Oslo.2.DEFINICION:Forma (Patn de Diseño) que utilizamos los programadores paraimplementar nuestras aplicaciones, además permite separar nuestraaplicación en un modelo, una vista y con controlador. Este patrón fueintroducido por primera vez en el lenguaje “Smalltalk”. [3]
 
Figura 10.10: Estructura de las clases del MVCPatrón de diseño de software probado y se sabe que funciona. Con MVCla aplicación se puede desarrollar rápidamente, de forma modular ymantenible. Separar las funciones de la aplicación en modelos, vistas ycontroladores hace que la aplicación sea muy ligera. Estascaracterísticas nuevas se añaden fácilmente y las antiguas tomanautomáticamente una forma nueva.El diseño modular permite a los diseñadores y a los desarrolladorestrabajar conjuntamente, así como realizar rápidamente el prototipado.Esta separación también permite hacer cambios en una parte de laaplicación sin que las demás se vean afecdtadas.
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...