Universidad “Mariano Gálvez”

Ingeniería en Sistemas de Información

8to. Semestre

Sección “A”

Desarrollo Web

Ing. Axel Aguilar

Arquitectura de Programación existentes N capas, MVC

Alvin Steve Padilla Meza

3090-10-11973

Mazatenango 24 de agosto del 2018.

 Índice
Tema………………………………………………………………… Pagina
Introducción……………………………………………………………… 3
Estructuración…………………………………………………………. 4-7
Conclusión……………………………………………………………… 8
Bibliografía...…………………………………………………………… 9
 Introducción
En el siguiente trabajo se presentará una investigación correspondiente al tema
denominado: “Arquitectura de Programación existentes de N capas, MVC” en la cual
se conocerá en primer lugar que es la Arquitectura de N Capas, también lo que es el
modelo MVC, cómo funcionan cada uno de ellos, también conoceremos todo lo
relacionado con las arquitecturas antes mencionadas, etc.
 Arquitectura de Programación existentes de N capas, MVC
Arquitectura de n 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).

Características de la Programación en Capas.

La programación por capas es una técnica de ingeniería de software propia de la programación

por objetos, éstos se organizan principalmente en 3 capas: la capa de presentación o frontera, la
capa de lógica de negocio o control, y la capa de datos.

Siguiendo el modelo, el desarrollador se asegura avanzar en la programación del proyecto de

una forma ordenada, lo cual beneficia en cuanto a reducción de costos por tiempo, debido a que
se podrá avanzar de manera más segura en el desarrollo, al ser dividida la aplicación general en
varios módulos y capas que pueden ser tratados de manera independiente y hasta en forma
paralela.

Por otra parte, otra característica importante de recalcar es la facilidad para las actualizaciones
de la aplicación. En este aspecto, la programación en capas juega un papel de suma importancia
ya que sigue un estándar conocido en el ambiente de desarrollo de aplicaciones, lo cual da al
programador una guía para hacer mejoras a la aplicación sin que esto sea una tarea tediosa y
desgastante, siguiendo el estándar

establecido para tal fin y dividiendo las tareas en partes específicas para cada capa del proyecto.

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.
Arquitectura de 2 niveles

La arquitectura en 2 niveles se utiliza para describir los sistemas cliente/servidor en donde el

cliente solicita recursos y el servidor responde directamente a la solicitud, con sus propios
recursos. Esto significa que el servidor no requiere otra aplicación para proporcionar parte del
servicio.

Arquitectura en 3 niveles

En la arquitectura en 3 niveles, existe un nivel intermediario. Esto significa que la arquitectura

generalmente está compartida por: Un cliente, es decir, el equipo que solicita los recursos,
equipado con una interfaz de usuario (generalmente un navegador Web) para la presentación. El
servidor de aplicaciones (también denominado software intermedio), cuya tarea es proporcionar
los recursos solicitados, pero que requiere de otro servidor para hacerlo. El servidor de datos,
que proporciona al servidor de aplicaciones los datos que requiere. Comparación entre ambos
tipos de arquitecturas La arquitectura en 2 niveles es, por lo tanto, una arquitectura
cliente/servidor en la que el servidor es polivalente, es decir, puede responder directamente a
todas las solicitudes de recursos del cliente. Sin embargo, en la arquitectura en 3 niveles, las
aplicaciones al nivel del servidor son descentralizadas de uno a otro, es decir, cada servidor se
especializa en una determinada tarea, (por ejemplo: servidor web/servidor de bases de datos).
La arquitectura en 3 niveles permite: Un mayor grado de flexibilidad Mayor seguridad, ya que la
seguridad se puede definir independientemente para cada servicio y en cada nivel Mejor
rendimiento, ya que las tareas se comparten entre servidores

Arquitectura de niveles múltiples

En la arquitectura en 3 niveles, cada servidor (nivel 2 y 3) realiza una tarea especializada (un
servicio). Por lo tanto, un servidor puede utilizar los servicios de otros servidores para
proporcionar su propio servicio. Por consiguiente, la arquitectura en 3 niveles es potencialmente
una arquitectura en N-niveles.

Ventajas y Desventajas

La programación en capas no es una técnica rígida que debe implementarse solamente de

una forma, sino que los desarrolladores de proyectos tienen múltiples maneras de implementarla
según las tecnologías y tendencias que se utilicen.
La satisfacción de los requerimientos del usuario es la base para escoger el modelo
de implementación a seguir. La tendencia a utilizar el modelo de programación en capas es
grande cuando se trata principalmente de aplicaciones empresariales donde se deben manejar
gran cantidad de subsistemas y módulos, así como generar reportes lo suficientemente
complejos como para necesitar un orden estricto a la hora de desarrollar el proyecto.

La evolución-revolución
La evolución
Las arquitecturas basadas en n-capas son el siguiente paso lógico en un proceso de evolución,
el cual, está basado en las arquitecturas convencionales cliente-servidor (2 y 3 capas) más la
convergencia de dos tecnologías tremendamente potentes:

Desarrollo de aplicaciones basadas en componentes - relacionado directamente con la

Programación Orientada a Objetos (Lenguajes y Técnicas)

Internet - primer ejemplo de un sistema complejo de n-capas cliente-servidor.

Los sistemas de n-capas utilizan técnicas de desarrollo basadas en componentes combinados

con los estándares abiertos de Internet, para crear aplicaciones multiplataforma muy potentes
con bajos costes, fáciles de mantener y con gran efectividad. Lo que realmente es nuevo en el
modelo de n-capas es la posibilidad de distribuir objetos independientes sobre el número de
capas que sean necesarias y enlazarlas dinámicamente, cuando sea necesario, para
proporcionar una flexibilidad ilimitada a la aplicación.

La revolución

Arquitectura en n-capas: Un sistema adoptivo

N-Tier forma parte también de un revolucionario proceso, actualmente en desarrollo, basado en

la aplicación de estas nuevas tecnologías (componentes y estándares de Internet). Estas
tecnologías son los bloques para crear Software de Negocio y Sistemas de Información
adaptables que ayuden a las empresas a integrar todos sus sistemas de Tecnologías de la
Información, así como las inversiones realizadas en éstos, mientras que obtienen una ventaja
clara en el uso de Internet.

Las empresas exitosas del futuro serán aquellas que se adapten mejor a un mundo conectado.
Los frameworks de n-capas utilizan herramientas basadas en Internet que proporcionan a los
clientes la adopción de las últimas y más potentes tecnologías que proporcionarán claros avances
competitivos. Las empresas hoy en día (no importa dónde estén, qué tamaño tengan o en qué
industria se encuentren) deben ser capaces de implementar las últimas prácticas de negocio,
ventas y estrategias de distribución, procesos de fabricación, logística de la cadena de suministro,
etc. Por eso, los sistemas basados en n-capas ayudan rápidamente a cambiar los negocios para
experimentar la compartición sin restricciones de datas a lo largo de aplicaciones o fuentes de
datos en la empresa, incluyendo Enterprise Resource Planning (ERP), aplicaciones hechas a
medida, empaquetadas, heredadas o bases de datos.
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. Comúnmente se encarga de comunicarse con
la base de datos mediante funciones que accederán a las tablas y realizarán las funciones
habituales de datos.
La Vista, o interfaz de usuario: que compone la información que se envía al cliente y los
mecanismos interacción con éste. También podemos decir que Se trata del código que nos
permitirá presentar los datos que el modelo nos proporciona, como ejemplo podríamos decir que
en una aplicación web es el código HTML que nos permite mostrar la salida de los datos
procesados.
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. También podemos decir que se encarga de enviar comandos al modelo para actualizar su
estado, y a la vista correspondiente para cambiar su presentación, pero no es el encargado de
manipular los datos ni de generar una salida.
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 los muestra 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:

 El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario
pulsa un botón, enlace, etc.)
 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). El modelo no debe tener conocimiento directo sobre la vista. Sin
embargo, se podría utilizar el patrón Observador para proveer cierta indirecció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.
 La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo
nuevamente.
Capas del modelo MVC
El modelo MVC (Modelo Vista Controlador), consta de las tres capas a las cuales hace alusión
su nombre, en la Capa de Vista, tenemos nuestros formularios realizados en HTML o ASP.NET
o JSP (Java Server Page) o JSF (Java Server Faces) o Razor con Helpers, este último para el
caso de desarrollos con Visual Studio con el frameworks MVC3 o MVC4.
Recordemos que, para el caso de desarrollos con Java o C#, podemos crear aplicativo stand –
alone (aplicativos que dibujan sus propias ventanas o formularios y no se visualizan a través de
un navegador web), conocidos también con el nombre de “aplicativos de escritorio”. Con este tipo
de aplicaciones no hablamos de HTML, como tampoco de CSS (hojas de estilo en cascada),
Jquery`s y controles Ajax; elementos propios de la capa de vista en aplicaciones web.
La Capa del Controlador: 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.
La Capa del Modelo: se refiere también a las clases que conforman el aplicativo, y por ende a la
información con la cual el sistema opera; además se compone por el SGBD (Sistema Gestor de
Bases de Datos), para este tendremos que agregar una capa de abstracción extra o ORM (Mapeo
de Objetos Relacional), este último permite mapear objetos de forma relacional, ya que las bases
de datos más utilizadas son relacionales.
Comprendiendo mejor al modelo MVC
Para comprender un poco más este patrón de diseño veamos cómo funciona en una aplicación
web común:
 El usuario solicita una acción al servidor
 El servidor atiende la petición y manda a llamar al controlador
 El controlador llama al modelo necesario
 El modelo atiende la petición y realiza las operaciones de datos
correspondientes
 El modelo regresa el resultado
 El controlador llama a la vista, enviándole los datos procesados del
modelo
 La vista presenta los datos
 El controlador devuelve la vista al servidor
 El servidor presenta el resultado al cliente
¿Por qué MVC es una estrella en el mundo del desarrollo web?
Aunque MVC es un patrón de diseño el cual fue ideado para aplicaciones de escritorio hace
unos 40 años (en los 70’s), resulta muy práctico en la web por varias razones:
Está enfocado en separar responsabilidades
Si en este momento estás pensando “y eso en que me afecta o beneficia” , pues pensemos un
poco en cómo están creadas las aplicaciones y sitios web actuales, HTML para los objetos o el
marcado , CSS para el estilo y JavaScript para la lógica, cada uno con su propio enfoque y su
propia responsabilidad, pues con MVC es lo mismo pero incluyendo los componentes que
mencionamos antes.
Reutilizar Código
Cualquier frameworks que creado a partir de MVC te permite reutilizar código, regresar vistas
totales o parciales, evitando duplicar estilos o contenido en las vistas. Todo el manejo de datos
se realiza en los modelos, por lo que si modificas tu base de datos solo es necesario modificar el
modelo correspondiente para que permita manejar los datos actualizados, sin necesidad de
actualizar cada lugar donde es utilizado.
Evitamos código Espagueti
Con este patrón de diseño reducimos y hasta eliminamos el uso de código de servidor y de
presentación en un mismo lugar.
Perfecto para equipos multidisciplinarios
Con este patrón de diseño reducimos y hasta eliminamos el uso de código de servidor y de
presentación en un mismo lugar. por lo que, si en tu equipo hay alguien encargado de maquetar
la aplicación, alguien más se encarga de crear las reglas de negocio y demás actividades, cada
uno puede trabajar independientemente del otro sin sufrir afectaciones.
 Conclusión
En el siguiente trabajo se presentó una investigación correspondiente al tema denominado:
“Arquitectura de Programación existentes de N capas, MVC” en esta investigación
aprendimos que 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. La programación por capas es una técnica de ingeniería de software propia de
la programación por objetos, éstos se organizan principalmente en 3 capas: la capa de
presentación o frontera, la capa de lógica de negocio o control, y la capa de datos. 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). 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 y Capa de datos: es donde residen
los datos y es la encargada de acceder a los mismos. También conocimos que el 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. También
podemos expresar que el modelo MVC cuenta con tres partes las cuales son:

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, También conocimos las Capas del modelo MVC, las cuales constan de las tres capas a
las cuales hace alusión su nombre, en la Capa de Vista, tenemos nuestros formularios realizados
en HTML o ASP.NET o JSP (Java Server Page) o JSF (Java Server Faces) o Razor con Helpers,
este último para el caso de desarrollos con Visual Studio con el frameworks MVC3 o MVC4.
La Capa del Controlador: responde a eventos o peticiones del usuario, e invoca cambios en el
modelo y muy seguramente en la vista.
La Capa del Modelo: se refiere también a las clases que conforman el aplicativo, y por ende a la
información con la cual el sistema opera; además se compone por el SGBD (Sistema Gestor de
Bases de Datos), para este tendremos que agregar una capa de abstracción extra o ORM (Mapeo
de Objetos Relacional), este último permite mapear objetos de forma relacional, ya que las bases
de datos más utilizadas son relacionales.
 Bibliografía

http://iutll-abdd.blogspot.com/2012/05/arquitectura-de-n-capas.html
https://www.academia.edu/10102692/Arquitectura_de_n_capas?auto=download
https://www.researchgate.net/profile/Elizabeth_Gonzaga/publication/287735179_Arquite
cturas_en_n-
Capas_Un_Sistema_Adaptivo/links/5697d43e08ae1c42790524a1/Arquitecturas-en-n-
Capas-Un-Sistema-Adaptivo.pdf?origin=publication_detail
https://davidjguru.wordpress.com/2010/02/08/la-arquitectura-de-tres-capas-introduccion/
http://iutll-abdd.blogspot.com/2012/05/arquitectura-de-n-capas.html
https://es.slideshare.net/alejandrouhu/mvc-vs-pnc-1-revaluacion