Está en la página 1de 6

Arquitectura

del Sistema
HCE

Av. Juan de Arona 748 of.202


San Isidro, Lima – Perú
Telefax: (511)222-6162, Telf. 221-7774
Correo electrónico: royalsys@royalsystems.net
Manual Arquitectura- HCE.docx

Mejores Procesos – CMMI Nivel III

Configuración
Documento de Arquitectura

Historial de Documento

Registro de Cambios
Fecha Versión Justificación Análisis Impacto Autor
20/10/2021 001.01_2021 Actualización Jordan Mateo

Distribución
Rol
Financial Controller
Usuario Líder
Usuario Clave

Propiedades del Documento


Ítem Detalle
Título del documento Arquitectura de desarrollo .NET MVC
Autor Royal Systems S.A.C.
Fecha de Creación 26/12/2012
Fecha de Actualización 20/07/2016

Revisiones
Observación Autor Estado

Royal Systems Pág. 2 de 8


Manual Arquitectura- HCE.docx

Mejores Procesos – CMMI Nivel III

Configuración
Documento de Arquitectura

Documento de Arquitectura

1. Introducción

La arquitectura de desarrollo define la estructura principal que seguirán todos los proyectos
basados en el lenguaje .NET, con el fin de estandarizar las capas de desarrollo, así como la
distribución dentro de los proyectos.

2. Arquitectura de aplicaciones

2.1. Arquitectura MVC

Es un patrón o modelo de abstracción de desarrollo de software que separa los datos de una
aplicación, la interfaz de usuario y la lógica de negocio en tres componentes distintos.

Modelo: Esta es la representación específica de la información con la cual el sistema opera.


En resumen, el modelo se limita de forma relativa a la vista y su controlador facilitando las
presentaciones visuales complejas.

Vista: Representa el objeto que maneja la presentación visual de los datos representados
por el Modelo. Genera una representación visual del Modelo y muestra los datos al usuario.
Interactúa con el Modelo a través de una referencia al propio Modelo.

Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones
al modelo y probablemente a la vista.

Aunque se pueden encontrar diferentes implementaciones de MVC, 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 reflejan 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. Este uso del patrón Observador no
es posible en las aplicaciones Web puesto que las clases de la vista están desconectadas
del modelo y del controlador. En general 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. Por ejemplo, en el MVC usado por
Royal Systems Pág. 3 de 8
Manual Arquitectura- HCE.docx

Mejores Procesos – CMMI Nivel III

Configuración
Documento de Arquitectura
Apple en su framework Cocoa. Suele citarse como Modelo-Interface-Control, una
variación del MVC más puro.

5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo


nuevamente....

2.2. Modelo en Capas

La programación en 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.

Capa de presentación: Es lo que ve el usuario final, captura la información ingresada por


el usuario. Esta capa es la primera en trabajar más el contenido de la comunicación que
como se establece la misma.

Capa de negocio: Es donde residen los programas que se ejecutan se procesa la


información enviada por el usuario, es aquí en donde se establece las reglas de negocio
que deben cumplirse. Esta capa se encuentre entre la capa de presentacióny capa de
datos, trabajando muchas veces como un puente en estas capas.

Capa de datos: Es la encargada de acceder a la información. Está formado por gestores


de base de datos en donde se almacena la información.

Royal Systems Pág. 4 de 8


Manual Arquitectura- HCE.docx

Mejores Procesos – CMMI Nivel III

Configuración
Documento de Arquitectura

2.3. Arquitectura de aplicación HCE

Presentación Negocio Datos

Responsive
web

Capa de presentación: EXT.NET/MVC se convirtió en la tecnología estándar para la capa de


presentación en aplicaciones web. Se implementa el patrón de diseño MVC con una clara separación
de responsabilidades. Se hace el uso del framework de EXT .NET/MVC Para las páginas html, Se
muestra mejor rendimiento en respuestas del servidor web.

Capa de Negocio: Se usa ASPNET, el framework no obliga a usar un modelo de programación en


particular lo que conlleva a una mejor integración con otras herramientas. Facilita la programación
transversal (programación orientada aaspectos) trabaja con distintos frameworks para el manejo de
las transacciones.

Royal Systems Pág. 5 de 8


Manual Arquitectura- HCE.docx

Mejores Procesos – CMMI Nivel III

Configuración
Documento de Arquitectura

Capa de Datos: El ENTITY FRAMEWORK representa un ORM que se encarga de enlazar al sistema
relacional con el sistema de objetos. La facilidad de programación es una de las ventajas más fuertes,
ya que la orientación a objetos facilita muchísimo la programación del CRUD.

Royal Systems Pág. 6 de 8

También podría gustarte