INSTITUTO TECNOLÓGICO SUPERIOR

DE TAMAZUNCHALE

INGENIERÍA EN SISTEMAS
COMPUTACIONALES
PROGRAMACIÓN WEB II

ACTIVIDAD: RESUMEN U2
“Patrón de diseño MVC para Programación
Web”

ALUMNA:
MARIA MACARIA BAUTISTA LUCIO
DOCENTE:
ING. JOSÉ GERMAN HERNANDEZ RAMIREZ

8° SEMESTRE M2
TAMAZUNCHALE S.L.P A 16 de marzo del 2020
 INDICE
...........................................................................................................................................................1
2.1 Conceptos y ventajas de los patrones de diseño........................................................................3
2.2 Modelo-Vista-Controlador (MVC)...............................................................................................5
2.2.1 Propósito y componentes (modelo, vista, controlador)..........................................................6
2.2.2 Características e implementación............................................................................................8
2.2.3 Ventajas del patrón de diseño MVC en aplicaciones web.......................................................9
2.3 Diseño de la arquitectura del proyecto MVC..............................................................................9
2.4 Plan de construcción del proyecto con base en MVC...............................................................11
.........................................................................................................................................................15
Referencias Bibliográficas...............................................................................................................18
2.1 Conceptos y ventajas de los patrones de diseño.

“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes

en el desarrollo de software.”
En otras palabras, brindan una solución ya probada y documentada a problemas
de desarrollo de software que están sujetos a contextos similares. Debemos tener
presente los siguientes elementos de un patrón: su nombre, el problema (cuando
aplicar un patrón), la solución (descripción abstracta del problema) y las
consecuencias (costos y beneficios).
Se clasifican de la siguiente manera:
 Patrones Creacionales: Inicialización y configuración de objetos.
 Patrones Estructurales: Separan la interfaz de la implementación. Se
ocupan de cómo las clases y objetos se agrupan, para formar estructuras
más grandes.
 Patrones de Comportamiento: Más que describir objetos o clases,
describen la comunicación entre ellos.

Conceptos básicos de un patrón:

 Un Nombre y clasificación: El nombre del patrón que lo identifique y lo

describa.
 Intención. ¿qué hace? ¿cuál es su lógica e intención? ¿qué problema es
capaz de manejar o solucionar?
 Otros nombres asociados, si tiene, por el cual es conocido en la comunidad.
 Motivo. Un escenario que ilustre el problema a resolver y como las clases y
objetos pueden solucionarlo.
 Aplicabilidad. En que situaciones se puede aplicar y como reconocerlos.
 Estructura. Representación grafica de las clases a usar en una notación
formal. En esta exposición se utilizará la notación Object Modeling
Technique ( OMT ). Se usaran también diagramas de interacción para
ilustrar peticiones y colaboraciones entre objetos.
  Participantes. Clases y objetos participantes del diseño y sus
responsabilidades.
 Colaboraciones. Como los participantes colaboran para transportar
responsabilidades.
 Consecuencias. Cómo el patrón logra sus objetivos. Resultados y costes
asociados. Que partes del sistema pueden variar de manera independiente
sin comprometer el objetivo.
 Implementación. Consejos, precauciones o técnicas a tener en cuenta
durante su implementación. Características especiales que debe soportar el
lenguaje a usar.
 Código de ejemplo. Fragmento en un lenguaje para ilustrar una
implementación concreta.
 Usos conocidos. Al menos dos ejemplos diferentes de sistemas reales
donde se ha usado el patrón.
 Patrones relacionados. Nombrar otros patrones con los que esté
relacionado, o pueda colaborar o pueda ser sustituido por, indicando
importantes diferencias y ventajas de usar uno frente al otro.

Ventajas de utilizar Patrones de diseño.

Para cubrir nuestras necesidades de se deben tomar en cuenta los aspectos de un

patrón que se deben evaluar:

 Resistencia al cambio: Se debe elegir el patrón que facilite lo más

posibles futuros cambios. Los cambios en un diseño no son probables, son
seguros, se producen con toda seguridad. A la hora de diseñar una solución
a un problema es conveniente abstraer el problema concreto a otro más
genérico y resolver este último. Los patrones consiguen precisamente esto.

 Reutilización: Este aspecto requiere una aclaración importante. La

reutilización de código resulta prácticamente imposible. En cambio, los
 diseños son mucho más reutilizables, pero ni siquiera tanto como las
propias ideas. Se debe tender a reutilizar las ideas. Por eso, cuando
hacemos un diseño debemos pensar en que nos debe ser útil para futuros
proyectos, en su esencia o filosofía, no en su estructura o implementación.

En general, la gran ventaja del uso de patrones es que minimizan el riesgo de

generar un mal diseño y permiten comunicar experiencias entre diseñadores.

2.2 Modelo-Vista-Controlador (MVC).

Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que

separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en
tres componentes distintos. Se trata de un modelo muy maduro y que ha
demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre
multitud de lenguajes y plataformas de desarrollo.

 El Modelo que contiene una representación de los datos que maneja el

sistema, su lógica de negocio, y sus mecanismos de persistencia.

 La Vista, o interfaz de usuario, que compone la información que se envía al

cliente y los mecanismos interacción con éste.

 El Controlador, que actúa como intermediario entre el Modelo y la Vista,

gestionando el flujo de información entre ellos y las transformaciones para
adaptar los datos a las necesidades de cada uno.
2.2.1 Propósito y componentes (modelo, vista,
controlador).

El modelo es el responsable de:

 Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo

sea independiente del sistema de almacenamiento.
 Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de
regla puede ser: "Si la mercancía pedida no está en el almacén, consultar el
tiempo de entrega estándar del proveedor".
 Lleva un registro de las vistas y controladores del sistema.
 Si estamos ante un modelo activo, notificará a las vistas los cambios que en
los datos pueda producir un agente externo (por ejemplo, un fichero por
lotes que actualiza los datos, un temporizador que desencadena una
inserción, etc.).

El controlador es responsable de:

 Recibe los eventos de entrada (un clic, un cambio en un campo de texto,

etc.).
 Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces
Acción W". Estas acciones pueden suponer peticiones al modelo o a las
vistas. Una de estas peticiones a las vistas puede ser una llamada al
método "Actualizar ()". Una petición al modelo puede ser
"Obtener_tiempo_de_entrega ( nueva_orden_de_venta )".

Las vistas son responsables de:

 Recibir datos del modelo y las muestras al usuario.

 Tienen un registro de su controlador asociado (normalmente porque
además lo instancia).
 Pueden dar el servicio de "Actualización ()", para que sea invocado por el
controlador o por el modelo (cuando es un modelo activo que informa de los
cambios en los datos producidos por otros agentes).
 El flujo que sigue el control generalmente es el siguiente:

1. El usuario interactúa con la interfaz de usuario de alguna forma (por

ejemplo, el usuario pulsa un botón, enlace, etc.)

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

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

4. 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). El modelo no debe tener
conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón
Observador para proveer cierta dirección entre el modelo y la vista, permitiendo al
 modelo notificar a los interesados de cualquier cambio. Un objeto vista puede
registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí
mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio
(el modelo) a la vista aunque puede dar la orden a la vista para que se actualice.
Nota: En algunas implementaciones la vista no tiene acceso directo al modelo,
dejando que el controlador envíe los datos del modelo a la vista.

5. La interfaz de usuario espera nuevas interacciones del usuario,

comenzando el ciclo nuevamente.

2.2.2 Características e implementación.

MVC fue desarrollado para aplicaciones de escritorio, ha sido ampliamente

adaptado como arquitectura para diseñar e implementar aplicaciones web en los
principales lenguajes de programación. Se han desarrollado multitud de
frameworks, comerciales y no comerciales, que implementan este patrón; estos
frameworks se diferencian básicamente en la interpretación de como las funciones
MVC se dividen entre cliente y servidor.

Los primeros frameworks MVC para desarrollo web planteaban un enfoque

de cliente ligero en el que casi todas las funciones, tanto de la vista, el modelo y el
controlador recaían en el servidor. En este enfoque, el cliente manda la petición de
cualquier hiperenlace o formulario al controlador y después recibe de la vista una
página completa y actualizada (u otro documento); tanto el modelo como el
controlador (y buena parte de la vista) están completamente alojados en el
servidor. Como las tecnologías web han madurado, ahora existen frameworks
como JavaScriptMVC, Backbone o jQuery14 que permiten que ciertos
componentes MVC se ejecuten parcial o totalmente en el cliente

 El modelo, las Vistas y los Controladores se tratan como entidades

separadas.
 Se utilizan en aplicaciones con interfaces sofisticadas
  Maneja gran cantidad de datos y transacciones complejas.

2.2.3 Ventajas del patrón de diseño MVC en

aplicaciones web.

Esta tecnología se centra en la escalabilidad, y permite a su vez dividir el trabajo

entre un grupo de profesionales, al estar sus componentes separados entre sí.
Entre las principales ventajas que puede ofrecernos un desarrollo MVC podemos
destacar las siguientes:

 La aplicaciones estas implementada modularmente.

 Crea independencia de funcionamiento.
 Las modificaciones a las vistas no afectan en absoluto a los otros módulos
de la aplicación.
 Sus vistas muestran información actualizada siempre
 Las modificaciones a las vistas no afectan en absoluto a los otros módulos
de la aplicación.

2.3 Diseño de la arquitectura del proyecto MVC.

Existen diferentes niveles de abstracción, cuando empezamos a escribir código lo

hacemos al más bajo nivel o sea al nivel de los requerimientos, de las
descripciones detalladas que nos permiten codificar esa lógica para que después
forme parte de algo mucho más grande.
 A continuación les explicare el modelo:

1. Nuestra aplicación debe seguir el patrón MVC, por lo tanto se espera que
contenga Controladores, Modelos y Vistas, mismos que podemos ver en los
cuadros verdes.
2. ASP.NET nos ofrece todo el entramado para que nuestra aplicación funcione en la
plataforma, he resaltado 3 partes en color azul oscuro: Ruteo, Mapeo y View
Engine.
3. Siguiendo los consejos que les he estado publicando en los artículos anteriores,
he recurrido a bibliotecas públicas instaladas desde NuGet, para reforzar la
seguridad de mi aplicación; estos los pueden componentes intervienen en el
mecanismo de Ruteo, validando los permisos del perfil al cual pertenece el
usuario que realiza la solicitud.
4. Así mismos, una vez que se ha verificado el acceso, se aplican reglas de
validación de datos para asegurarnos que la información que ha llegado cumple
con nuestras reglas y de esta manera prevenir que algún usuario malicioso nos
envié datos no válidos.
5. Una vez que estos datos han sido validados el flujo de la aplicación lo toma el
controller, en este momento la lógica del Controlador determina si se debe
continuar o si deberá ser re direccionado, ya sea por un error o por condiciones
especiales. El Controller deriva de una clase base que contiene código
reutilizable.
6. Si el Controlador determina que el flujo debe seguir, los datos pasaran a un
servicio para que se haga cargo de la acción CRUD correspondiente; hasta este
momento los datos se encuentran en un ViewModel.
7. El servicio recibe el VM los procesa según la lógica de negocio, lo convierte a una
entidad que el repositorio pueda usar y se lo envía para tomar las acciones
pertinentes. El servicio implementa una interface predefinida, que me asegura que
 todos los servicios mantengan la misma estructura así como un mínimo de
métodos requeridos para responder las acciones del CRUD.
8. El repositorio por su parte es una clase Genérica que es capaz de adaptarse
mecanismo de persistencia que se haya configurado, pudiendo ser MySQL, SQL,
etc. Esta clase contiene los métodos básicos del CRUD; si se requiere algún
método especial, es posible extenderla para añadir estos métodos personalizados.
9. Si se trata de una consulta el repositorio responderá con una entidad o una
colección de estos; el servicio recibe estas entidades, las convierte en VM y las
devuelve al controlador. El controlador envía estos datos al ViewEngine
encapsulados en el VM para que sean convertidos en una respuesta usando la
vista correspondiente.
10. La vista convertida en HTML, CSS, JavaScript, etc. es enviada de regreso
al usuario que ha realizado la solicitud.

El nivel más alto de abstracción de un sistema es aquel donde podemos ver

toda la estructura, sus componentes y las relaciones que estas partes tienen entre
sí; si quieren podemos decir que el termino ARQUITECTURA DE SOFTWARE es
una analogía que hace referencia a la construcción de edificios. Algunos prefieren
decirle diseño del software. Existen muchas formas de representar este tipo de
diseños, algunos se basan en los datos, otros en las operaciones, el flujo de la
lógica, etc. Lo más importante es que estos diagramas pueden servir como guía
para todos los implicados en el desarrollo de un sistema.

2.4 Plan de construcción del proyecto con base en

MVC.

Gestión de libros

Para poner en práctica cómo funcionan los controladores vamos a

desarrollar una sencilla web que gestionen los libros o revistas del Servicio de
Informática.
 No vamos a usar base de datos o para entender todos los conceptos. Cuando lo
tengamos acabado, con unos pequeños cambios, lo tendremos en base de datos.

El proyecto lo llamaremos CSI-Biblioteca y usamos el modelo de libro que hemos

utilizado anteriormente (se arrastra desde el explorador)

Crearemos un modelo llamado Biblioteca que incluya un listado de libros y que al

crearse, añada unos libros por defecto (por tener unos datos por efecto)

public class Biblioteca

    {
      public List<Libro> Libros { get; set; }
 
      public Biblioteca()
       {
        Libros = new List<Libro>
           {
new Libro { Isbn = "11122", Titulo = "Los Piratas del Caribe", TipoLibro  =
"Novela"},
new Libro { Isbn = "22211", Titulo = "Los Pilares de la tierra", TipoLibro  =
"Novela"},
   
new Libro { Isbn = "33311", Titulo = "Steve Jobs", TipoLibro  = "Biografía"}
                                   };
        }
    }

Ahora sería el momento de crear el controlador con todos los métodos generales
para poder dar de alta, editar o borrar libros de la biblioteca.

Aunque se puede hacer a mano como lo hemos hecho hasta ahora, ASP.NET
MVC incluye muchos asistentes para facilitar tareas rutinarias.

Pulsamos botón derecho en la carpeta Controllers, y seleccionar Agregrar >

Controller.

En la ventana que habíamos visto antes, ponemos el nombre del nuevo

controlador BibliotecaController y en la plantilla/template seleccionamos “Controller
with empty read/write actions”
Veremos que nos
aparecen muchos métodos vacíos, con la forma de llamarlos vía web como
comentario. Los métodos se corresponden con todas las operaciones generales.
Podemos añadir las que necesitemos o quitar las que no se vayan a usar.
        //
        // GET: /Biblioteca/
 
        public ActionResult Index()
        {
            return View();
        }
 
        //
        // GET: /Biblioteca/Details/5
 
        public ActionResult Details(int id)
        {
            return View();
        }

Como nosotros queremos hacer uso del modelo Biblioteca que hemos definido
anteriormente, antes de cualquier método del controllador debemos crear un
objeto del tipo de esa clase.

public class BibliotecaController : Controller

    {
        Biblioteca miBiblioteca = new Biblioteca();

Una posible implementación del método Index podría ser

public ActionResult Index()

        {
            return
View(miBiblioteca.Libros.ToList());
        }
Ahora para crear la vista, pulsamos dentro del método el botón derecho y
seleccionamos la primer opción Add View...

Ahora vamos a probar la potencia de las vistas marcando la casilla “Create a

strongly-typed view” y seleccionado en Model class la clase Libro (no confundir
con Biblioteca porque lo que queremos listar sonlibros y es lo que pasamos a la
vista) y en Scaffold template seleccionamos List.

En muchas ocasiones no os
aparecerán los modelos en el mismo momento que se crean, deberemos pulsar
F6 para que se compile el proyecto y todos los modelos sean visibles desde el
resto de elementos del proyecto.

Se genera un código que permite la visualización, el alta, la edición y el borrado de

libros.

@model IEnumerable<CSI_Biblioteca.Models.Libro>
 
@{
    ViewBag.Title = "Index";
}
 
<h2>Index</h2>
 
<p>
    @Html.ActionLink("Create New", "Create")
</p>
<table>
    <tr>
        <th>
            Isbn
        </th>
        <th>
El resultado es

El resto de métodos se
implementan de una forma similar.

Vamos a incorporar dos métodos adicionales al modelo Biblioteca que usaremos

desde el controlador.

  public int NumeroLibros()

        {
            return Libros.Count();
        }
 
        public Libro ObtenerPorIsbn(string isbn)
        {
            foreach (var libroBuscar in Libros)
            {
                if (libroBuscar.Isbn == isbn)
                {
                    return libroBuscar;
                }               
            }
 
            return null;
        }

En el controlador vamos a cambiar la declaración del objeto porque si no los

cambios que hagamos alta o baja no se refejarán (en cada llamada se redeclara el

objeto). Añadomos static para que los datos se mantengan entre llamadas.
    static Biblioteca miBiblioteca = new Biblioteca();

Detallamos la operación de creación. Nos vamos al método Create. Lo primero

que nos damos cuenta es que hay dos. El primero es el que nos solicita los datos
del libro y el segundo el que lo crea realmente (funciona con el método POST).

En el primer método Create pulsamos el botón derecho Add View… y

seleccionamos Libro como Model class y Create como Scaffold template

Si lo visualizamos (pulsando en Create New del

listado de libros), visualizaremos todos los cambios de un libro. No pulsar Create
hasta que
definamos el
segundo método.

Al segundo método le añadimos el código para dar de alta un libro a la biblioteca

[HttpPost]
        public ActionResult Create(FormCollection collection)
        {
            try
            {        
                miBiblioteca.Libros.Add(new Libro
                                            {
                                               Isbn =  (miBiblioteca.Libros.Count() +
1).ToString(),
                                               Titulo = collection["Titulo"],
                                               TipoLibro = collection["Categoria"]
                                            });
 
                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }

En caso de que sea todo correcto le redirigimos al listado de libros (donde ya ser
verá el nuevo) y en caso de que falle volvemos a mostrar la vista de creación que
hemos definido anteriormente.

Rellenamos el formulario
Pulsamos Create y vemos en el listado el nuevo libro.

Referencias Bibliográficas

Anónimo. (s.f). Conceptos de Programación. Recuperado de

https://sites.google.com/site/conceptoprogramacion/Home/patrones

Ciberaula. (2019). Ventajas_patrones. Recuperado de

https://www.ciberaula.com/articulo/ventajas_patrones/

si.ua.es (s.f). Modelo vista controlador (MVC) Recuperado de

https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-
controlador-mvc.html

Aguilar J.M. (15 de octubre de 2019). ¿Qué es el patrón MVC en programación y

por qué es útil? Recuperado de
https://www.campusmvp.es/recursos/post/que-es-el-patron-mvc-en-
programacion-y-por-que-es-util.aspx

Marketiweb. (2019). ¿Qué es la arquitectura MVC y cuáles son sus ventajas?

Recuperado de https://marketiweb.com/empresa/blog/item/114-que-es-la-
arquitectura-mvc-y-cuales-son-sus-ventajas

Cuevas, E.(2 de marzo de 2016). MVC(Modelo-Vista-Controlador). Recuperado de

https://prezi.com/yslnu82y6lmh/mvcmodelo-vista-controlador/
Ojeda J. (12 de marzo de 2015) La arquitectura de mis proyectos MVC.

[Mensaje de blog]http://msaspnetmvc.blogspot.com/2015/03/la-arquitectura-de-
mis-proyectos-mvc.html