Ensayo

Patrones diseño de software

Ingeniería de sistemas

ENSAYO DE MVC, MV-V|M, MVP

YHALEITZA FERNANDA JAIMES BOHORQUEZ

UNIVERSIDAD DE SANTANDER (UDES).

CÚCUTA (NORTE DE SANTANDER).

PATRONES DISEÑO DE SOFTWARE

MAYO 2020
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

ENSAYO DE MVC, MV-VM, MVP

YHALEITZA FERNANDA JAIMES BOHORQUEZ

ING. JONATHAN ROLANDO REY CASTILLO

UNIVERSIDAD DE SANTANDER (UDES).

CÚCUTA (NORTE DE SANTANDER).

PATRONES DISEÑO DE SOFTWARE

MAYO 2020
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

TABLA DE CONTENIDO

ABSTRACT......................................................................................................................4

PALABRAS CLAVES.....................................................................................................5

INTRODUCCION............................................................................................................6

DESARROLLO................................................................................................................7

CONCLUSIONES..........................................................................................................14

REFERENCIAS.............................................................................................................15
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

ABSTRACT

Reconocer la información o determinar las características de temas específicos

principalmente en de los famosos patrones o software que ofrecen soluciones a problemas

en la ingeniería de software llamados patrones arquetipos determinando específicamente

cuáles son sus elementos, que tipo de relación si son de solucionadores de problemas o

ayudan al problema de rendimiento, teniendo en cuenta sus usos y características y en este

presente tema se tomará en cuenta porque estos patrones son importantes y necesarios para

la ingeniería y porque son capaces de mejorar y ofrecer calidades deseadas para el

sistema.

Recognize the information or determine the characteristics of specific subjects mainly in

of the famous patterns or software that offer solutions to problems in software engineering

called patterns archetypes determining specifically which are their elements, what type of

relationship if they are of problem solvers or help to the performance problem, taking into

account their uses and characteristics and in this present topic will be taken into account

because these patterns are important and necessary for engineering and because they are

able to improve and offer desired qualities for the system.

 Ensayo

Patrones diseño de software

Ingeniería de sistemas

PALABRAS CLAVES

 Arquitectura

 Modelo

 Vista

 Controlador

 Presentación

 Software

 Architecture

 Model

 View

 Driver

 Presentation

 Software
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

INTRODUCCION

En el presente ensayo hace referencia a los patrones de arquitectura de software como lo

es MVC, MV-VM, MVP con el que nos da a conocer las diferentes entre las misma y que

se puede llevar a que cualquier persona pueda fácilmente mejorar, actualizar, modificar o

arreglar cualquier parte de la aplicación, en el cual se dio a conocer su historia, su utilidad,

pros y contras de las arquitecturas a tratar.

In this essay he refers to software architecture patterns such as MVC, MV-VM, MVP

with which he lets us know the differences between them and which can lead anyone to

easily improve, update, modify or fix any part of the application, in which his history, his

usefulness, pros and cons of the architectures to be dealt with were made known.
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

DESARROLLO

MVC (Modelo Vista Controlador), porque en este patrón de diseño se separan los datos

de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes

distintos. Cuando la lógica de negocio realiza un cambio, es necesario que ella sea la que

actualiza la vista.

Es un método con el que separarás la lógica del programa, el diseño de la aplicación y de

los cálculos que tengas que hacer. Entre las numerosas ventajas que te ofrece, la

principal con la que te vas a encontrar es la facilidad de coger tu código dentro de unos

cuantos meses, ver por dónde lo dejaste y hacerlo crecer sin complicarte la vida. Como

cualquier otro patrón de diseño, únicamente es útil si sigues el estilo que debes usar.

Fue introducido por Trygve Reenskaug en Smalltalk-76 durante su visita a Xerox

Parc en los años 70 y, seguidamente, en los años 80, Jim Althoff y otros implementaron

una versión de MVC para la biblioteca de clases de Smalltalk-80. Solo más tarde, en

1988, MVC se expresó como un concepto general en un artículo sobre Smalltalk-80.

Fue diseñada para reducir el esfuerzo de programación necesario en la implementación

de sistemas múltiples y la sincronización de datos.

Model: La capa de datos, responsable de manejar la conexión con la base de datos o una

API.

View: Será nuestra interfaz, la visualización de nuestro model. Tanto botones, campos

de texto y más.
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

Controller: Tendrá la lógica de negocio, puede tener la lógica qué realizará un botón al

hacerle click, llevarnos a otro vista, actualizar, decirle al modelo que traiga datos o más.

MV-VM (Modelo Vista Vista Modelo), porque en este patrón de diseño se separan los

datos de la aplicación, la interfaz de usuario pero en vez de controlar manualmente los

cambios en la vista o en los datos, estos se actualizan directamente cuando sucede un

cambio en ellos, por ejemplo si la vista actualiza un dato que está presentando se

actualiza el modelo automáticamente y viceversa.

En el año 2004, un grupo de desarrollo de Microsoft trabajaba en un proyecto

denominado "Avalon", más conocido por su nombre definitivo WPF (Windows

Presentation Foundation). El propósito de dicho proyecto era permitir el desarrollo de

aplicaciones de escritorio más completas y con un aspecto visual mucho más logrado y

complejo de lo que era posible con Windows Forms.

Al año siguiente John Gossman (miembro del equipo de desarrollo de "Avalon"), en

un artículo de la MSDN,  mostraba al público el patrón MVVM. En el artículo, MVVM

se presenta como una variación del patrón MVC ajustado a "WPF" y a su sistema de

enlace a datos, aunque realmente es una adaptación del patrón  "presentation model"

creado por el mítico Martin Fowler.

MMVM también nos va a permitir, con mucha facilidad, poder hacer test unitarios (Unit

Tests) y poder testear mejor nuestras aplicaciones.

Si estáis familiarizados con el desarrollo, esta arquitectura os recordará al Modelo Vista

Controlador (MVC), ya que las bases de ambas arquitecturas son muy parecidas. La

diferencia principal entre ambas es que la iteración de MMVVM funciona de otra forma.
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

Model: Igual que en arquitecturas anteriores.

View: Sigue siendo responsable de la visualización de los datos. Se une con variables y

acciones de una forma flexible.

ViewModel: Es el responsable de envolver el modelo y prepara los datos observables

necesitados por la vista. También proporciona enlaces a la vista para pasarle eventos al

modelo. Los cambios en el ViewModel cambian automáticamente la vista y viceversa.

MVP (Modelo Vista Presentador) es uno de los patrones de arquitectura de desarrollo

más comunes y usados en el desarrollo nativo de Android. La necesidad de utilizar este

patrón surge debido a lo complicado que puede llegar a ser el mantenimiento y

escalamiento de un proyecto que va creciendo a lo largo del tiempo y líneas de código.

El uso de esta arquitectura lleva a que cualquier persona pueda fácilmente mejorar,

actualizar, modificar o arreglar cualquier parte de la aplicación. Si bien aunque el patrón

MVP establece una serie de lineamientos, debemos tener en cuenta que cada proyecto

puede llegar a implementarlo con algunas variaciones, por lo que no es una solución

absoluta.

Model: Igual que en MVC, no hay cambios acá.

View: Ahora el Activity/Fragment es considerado parte de la vista y dejamos de tenerlo

en el Controller como ocurre en la arquitectura anterior.

Presenter: Es como el Controller de MVC, pero va a estar orquestando todo lo que

sucede. Es como un mesero qué se comunicará con el cocinero (modelo) para traer lo

que pide la vista. Debería haber un Presenter por cada Activity o Fragment.
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

En el MVC, el modelo notifica a la vista cualquier cambio que sufra el estado del

modelo. La información puede pasarse en la propia notificación, o después de la

notificación, la vista puede consultar el modelo directamente para obtener los datos

actualizados. Por el contrario, en el MVP, la vista no sabe nada sobre el modelo y la

función del presentador es la de mediar entre ambos, enlazando los datos con la vista.

En el modelo MVC, la vista tiende a tener más lógica porque es responsable de manejar

las notificaciones del modelo y de procesar los datos. En el modelo MVP, esa lógica se

encuentra en el presentador, haciendo a la vista “estúpida”. Su única función es

representar la información que el presentador le ha proporcionado.

En MVC, el modelo tiene lógica extra para interactuar con la vista. En el MVP, esta

lógica se encontraría en el presentador.

MVC (Model View Controller), because this design pattern separates the data of an

application, the user interface, and the business logic into three distinct components. When

the business logic makes a change, it needs to be the one that updates the view.

This is a method that separates the program logic, the application design, and the

calculations you have to do. Among the many advantages it offers, the main one you will

find is the ease of taking your code in a few months, see where you left off and make it

grow without complicating your life. Like any other design pattern, it is only useful if you

follow the style you should use.

 Ensayo

Patrones diseño de software

Ingeniería de sistemas

It was introduced by Trygve Reenskaug at Smalltalk-76 during his visit to Xerox Parc in

the 1970s, and then in the 1980s, Jim Althoff and others implemented a version of MVC

for the Smalltalk-80 class library. Only later, in 1988, was MVC expressed as a general

concept in an article about Smalltalk-80.

It was designed to reduce the programming effort required in the implementation of

multiple systems and data synchronization.

Model: The data layer, responsible for handling the connection to the database or an API.

View: It will be our interface, the visualization of our model. Both buttons, text fields and

more.

Controller: You will have the business logic, you can have the logic of what a button will

do when you click it, take us to another view, update, tell the model to bring data or more.

MV-VM (Model View Model View), because in this design pattern the data is separated

from the application, the user interface but instead of manually controlling changes in the

view or the data, the data is updated directly when a change in the data occurs, for example

if the view updates a data being presented the model is updated automatically and vice

versa.

In 2004, a Microsoft development group was working on a project called "Avalon", better

known by its definitive name WPF (Windows Presentation Foundation). The purpose of

this project was to enable the development of more complete desktop applications with a

much more accomplished and complex visual appearance than was possible with Windows

Forms.
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

The following year John Gossman (member of the "Avalon" development team), in an

article in the MSDN, showed the MVVM pattern to the public. In the article, MVVM is

presented as a variation of the MVC pattern adjusted to "WPF" and its data link system,

although it is actually an adaptation of the "presentation model" pattern created by the

mythical Martin Fowler.

MVVM will also allow us, very easily, to be able to do unit tests and to be able to test our

applications better.

If you are familiar with the development, this architecture will remind you of the Model

View Controller (MVC), as the bases of both architectures are very similar. The main

difference between both is that the MMVVM iteration works differently.

Model: Same as in previous architectures.

View: Still responsible for the visualization of the data. It joins with variables and actions

in a flexible way.

ViewModel: Is responsible for wrapping the model and preparing the observable data

needed by the view. It also provides links to the view to pass events to the model. Changes

in the ViewModel automatically change the view and vice versa.

MVP (Model View Presenter) is one of the most common development architecture

patterns used in native Android development. The need to use this pattern arises due to how

complicated the maintenance and scaling of a project can be, as it grows over time and lines

of code. The use of this architecture means that anyone can easily improve, update, modify

or fix any part of the application. Although the MVP pattern establishes a series of
 Ensayo

Patrones diseño de software

Ingeniería de sistemas

guidelines, we must take into account that each project can implement it with some

variations, so it is not an absolute solution.

Model: As in MVC, there are no changes here.

View: Now the Activity/Fragment is considered part of the view and we no longer have it

in the Controller as in the previous architecture.

Presenter: It's like the MVC Controller, but it will be orchestrating everything that happens.

It's like a waiter who will communicate with the cook (model) to bring what the view asks

for. There should be a Presenter for each Activity or Fragment.

In the MVC, the model notifies the audience of any changes in the model's status. The

information can be passed on in the notification itself, or after the notification, the view can

query the model directly for updated data. In contrast, in MVP, the view knows nothing

about the model and the role of the presenter is to mediate between the two by linking the

data to the view.

In the MVC model, the view tends to be more logical because it is responsible for handling

the model's notifications and processing the data. In the MVP model, that logic is found in

the presenter, making the view "stupid". Its only function is to represent the information

that the presenter has provided.

In MVC, the model has extra logic to interact with the view. In MVP, this logic would be

found in the presenter.

 Ensayo

Patrones diseño de software

Ingeniería de sistemas

CONCLUSIONES

Se determina que las características principales de las arquitecturas de software

propuestas en este ensayo se dan por un énfasis específico de los temas tratados que

generan pros y contras para así conocer de una manera más asertiva estas arquitecturas.

It is determined that the main characteristics of the software architectures proposed in

this essay are given by a specific emphasis of the topics discussed that generate pros and

cons in order to know in a more assertive way these architectures.

 Ensayo

Patrones diseño de software

Ingeniería de sistemas

REFERENCIAS

 Introducción a MVC con PHP y CodeIgniter /Media vida

 Arquitectura de Software

 http://theartoftheleftfoot.blogspot.com.es/2010/10/el-patron-modelo-vista-

presentador-mvp.html