ASP.

NET CORE WEB

APPLICATION
DISEÑO BACKEND API REST
 ARQUITECTURA DE SOFTWARE:
MONOLÍTICA - CAPAS
• La separación generalmente involucra funciones asignadas a una de tres capas:
1.Capa de interfaz de usuario (UI) – donde se produce toda la presentación y la interacción
del usuario. Los datos se muestran al usuario. El usuario envía y también recibe datos. Front
End
2.Capa de lógica de negocios (BLL) – como hemos señalado, el BLL se ocupa del
procesamiento de aplicaciones y coordina el flujo de datos entre la interfaz de usuario y
DAL. INTERFAZ - REPOSITORIO - SERVICIOS
3.Capa de acceso a datos (DAL) – o la capa donde se almacenan los datos gestión tiene lugar
En la mayoría de los casos, esto es a través de un servicio web o una base de datos.
ENTIDADES – VALIDACIONES – MENSAJES - DBCONTEXT
 ¿QUÉ ES UNA APLICACIÓN MONOLÍTICA?

• Una aplicación monolítica es aquella completamente independiente, en términos de

su comportamiento. Puede interactuar con otros servicios o almacenes de datos en
el transcurso de sus operaciones, pero el núcleo de su comportamiento se ejecuta
dentro de su propio proceso y toda la aplicación normalmente se implementa como
una única unidad. Si es necesario escalar horizontalmente este tipo de aplicación,
normalmente la aplicación completa se duplica en varios servidores o máquinas
 APLICACIONES TODO EN UNO

• El menor número posible de proyectos para una arquitectura de aplicación es uno.

En esta arquitectura, toda la lógica de la aplicación está contenida en un solo
proyecto, se compila en un único ensamblado y se implementa como una sola
unidad.
• Un proyecto nuevo de ASP.NET Core, independientemente de que se cree en Visual
Studio o desde la línea de comandos, empieza como un simple monolito "todo en
uno". Contiene todo el comportamiento de la aplicación, incluida la lógica de
presentación, de negocios y de acceso a datos..
 ¿QUÉ SON LAS CAPAS?

• Cuando aumenta la complejidad de las aplicaciones, una manera de administrarla

consiste en dividir la aplicación según sus responsabilidades o intereses. Este
enfoque sigue el principio de separación de intereses y puede ayudar a mantener
organizado un código base que crece para que los desarrolladores puedan
encontrar fácilmente dónde se implementa una función determinada. Pero la
arquitectura en capas ofrece una serie de ventajas que van más allá de la simple
organización del código.
 ARQUITECTURAS
TRADICIONALES N CAPAS
• Estas capas se suelen abreviar como UI (interfaz de usuario), BLL (capa de lógica de
negocios) y DAL (capa de acceso a datos). Con esta arquitectura, los usuarios
realizan solicitudes a través de la capa de interfaz de usuario, que interactúa con la
capa BLL. BLL, a su vez, puede llamar a DAL para las solicitudes de acceso de datos.
La capa de interfaz de usuario no debe realizar solicitudes directamente a DAL, ni
debe interactuar con la persistencia de forma directa a través de otros medios. Del
mismo modo, BLL solo debe interactuar con la persistencia a través de DAL. De este
modo, cada capa tiene su propia responsabilidad conocida.
• Una desventaja de este enfoque de distribución en capas tradicional es que las
dependencias de tiempo de compilación se ejecutan desde la parte superior a la
inferior. Es decir, la capa de interfaz de usuario depende de BLL, que depende de
DAL. Esto significa que BLL, que normalmente contiene la lógica más importante de
la aplicación, depende de los detalles de implementación del acceso a datos (y a
menudo de la existencia de una base de datos). Probar la lógica de negocios en este
tipo de arquitectura suele ser difícil, y requiere una base de datos de prueba.
• Aunque en esta aplicación se usan varios proyectos por motivos organizativos, se
sigue implementando como una sola unidad y sus clientes interactúan con ella
como una sola aplicación web. Esto permite que el proceso de implementación sea
muy simple. En la figura 5-4 se muestra cómo se podría hospedar este tipo de
aplicación con Azure.
 ARQUITECTURA LIMPIA

• Las aplicaciones que siguen el principio de inversión de dependencias, así como los
principios de diseño controlado por dominios (DDD), tienden a llegar a una
arquitectura similar. Esta arquitectura ha pasado por muchos nombres con los años.
Uno de los primeros nombres fue Arquitectura hexagonal, seguido por Puertos y
adaptadores. Más recientemente, se ha citado como arquitectura
cebolla o arquitectura limpia. Este último nombre, Arquitectura limpia, es el que se
usa para esta arquitectura en este libro electrónico.
• En el anterior diagrama, las dependencias fluyen hacia el círculo más interno. El
núcleo de la aplicación toma su nombre de su posición en el núcleo de este
diagrama. Y en el diagrama puede ver que el núcleo de la aplicación no tiene
dependencias de otros niveles de la aplicación. Las entidades e interfaces de la
aplicación se encuentran justo en el centro. En el exterior, pero todavía en el núcleo
de la aplicación, están los servicios de dominio, que normalmente implementan
interfaces definidas en el círculo interior. Fuera del núcleo de la aplicación, las capas
de la interfaz de usuario y la infraestructura dependen del núcleo de la aplicación,
pero no una de la otra (necesariamente).
 OTROS ESTILOS DE ARQUITECTURA DE
APLICACIONES WEB

• Web-Queue-Worker: los componentes principales de esta arquitectura son un front-

end web que atiende las solicitudes de cliente y un trabajo que realiza tareas que
consumen muchos recursos, flujos de trabajo de larga duración o trabajos por lotes.
El front-end web se comunica con el trabajo a través de una cola de mensajes.
• N niveles: una arquitectura de n niveles divide una aplicación en capas lógicas y
niveles físicos.
• Microservicio: una arquitectura de microservicios consta de una colección de
servicios pequeños y autónomos. Cada uno de servicio es independiente y debe
implementar una funcionalidad de negocio individual dentro de un contexto
delimitado.
 BIBLIOTECAS DE CLASES

• Las bibliotecas de clases son el concepto de biblioteca compartida de . NET. Le

permiten dividir funcionalidades útiles en módulos que pueden usar varias
aplicaciones. También se pueden usar para cargar la funcionalidad no necesaria o
no conocida al inicio de la aplicación.
 MIGRATIONS EF
• En proyectos reales, los modelos de datos cambian a medida que se implementan
características: se agregan o se quitan nuevas entidades o propiedades, y los
esquemas de base de datos se deben cambiar según corresponda para mantenerlos
sincronizados con la aplicación. La característica de migraciones de EF Core
proporciona una manera de actualizar incrementalmente el esquema de la base de
datos para mantenerla sincronizada con el modelo de datos de la aplicación al
tiempo que se conservan los datos existentes en la base de datos.

• CREAR MIGRACIONES EF
 CREAR CLASES
• public partial class Genero
• {
• public Genero()
• {
• Pelicula = new HashSet<Pelicula>();
• }
• [Key]
• public int Id { get; set; }
• [Required]
• [StringLength(50)]
• public string Nombre { get; set; }
• public string Caracteristicas { get; set; }

• public virtual ICollection<Pelicula> Pelicula { get; set; }

• }
• public partial class Pelicula
• {
• public int Id { get; set; }
• public string Nombre { get; set; }
• public DateTime FechaEstreno { get; set; }
• public string DuracionMinutos { get; set; }
• public int? IdGenero { get; set; }
• public string Sinopsis { get; set; }

• public virtual Genero IdGeneroNavigation { get; set; }

• }
DATACONTEXT
 INTERFAZ Y REPOSITORIO

• El patrón repositorio consiste en separar la lógica que recupera los datos y los asigna

a un modelo de entidad de la lógica de negocios que actúa sobre el modelo, esto
permite que la lógica de negocios sea independiente del tipo de dato que comprende la
capa de origen de datos, en pocas palabras un repositorio media. 

• Una interfaz define un contrato. Cualquier class o struct que implemente ese contrato

debe proporcionar una implementación de los miembros definidos en la interfaz.
Una interfaz puede definir una implementación predeterminada para los miembros.
 INTERFAZ
• public interface IRepositorio
• {
• Task<GeneroDTO> CreateGeneroAsync(GeneroDTO genero);
• Task<bool> DeleteGeneroAsync(int id);
• GeneroDTO GetGeneroById(int id);
• IEnumerable<GeneroDTO> GetAll();
• Task<bool> UpdateGeneroAsync(GeneroDTO genero);
• }
 REPOSITORIO
• public class GeneroRepositorio : IRepositorio
• {
• private readonly AlquilerPeliculasContext _context;

• public GeneroRepositorio(AlquilerPeliculasContext context)

• {
• _context = context;
•
• }
 GETALL
• public IEnumerable<GeneroDTO> GetAll()
• {
• var _genero = _context.Genero.Select(g => new GeneroDTO()
• {
• Id = g.Id,
• Nombre = g.Nombre,
• Caracteristicas = g.Caracteristicas
• }).ToList();
• return _genero;
• }
• public async Task<bool> DeleteGeneroAsync(int id)
• {
• try
• {
• var entity = new Genero()
• {
• Id = id
• };
• _context.Genero.Attach(entity);
• _context.Genero.Remove(entity);
• await _context.SaveChangesAsync();
• return true;
• }
• catch (Exception ex)
• {
• throw new Exception(ex.Message);
• }

• }
• public GeneroDTO GetGeneroById(int id)
• {
• var _genero = _context.Genero.Select(g => new GeneroDTO()
• {
• Id = g.Id,
• Nombre = g.Nombre,
• Caracteristicas = g.Caracteristicas
• }).FirstOrDefault(g => g.Id == id);
• return _genero;
• }
• public async Task<bool> UpdateGeneroAsync(GeneroDTO genero)
• {
• var entity = await _context.Genero.FirstOrDefaultAsync(e => e.Id ==
genero.Id);
• entity.Nombre = genero.Nombre;
• entity.Caracteristicas = genero.Caracteristicas;

• entity.Id = genero.Id;
• await _context.SaveChangesAsync();
• return true;

• }
• public async Task<GeneroDTO> CreateGeneroAsync(GeneroDTO genero)
• {
• try
• {
• var entity = new Genero()
• {
• Nombre = genero.Nombre,
• Caracteristicas = genero.Caracteristicas
• };
• _context.Genero.Add(entity);
• await _context.SaveChangesAsync();
• return genero;
• }
• catch (Exception ex)
• {
• throw new Exception(ex.Message);
• }
• }
 CONTROLADOR
• namespace ApiPeliculas.Controllers
• {
• [Route("api/[controller]")]
• [ApiController]
• public class GeneroController : ControllerBase
• {
• private readonly IRepositorio _generoRepositorio;
• public GeneroController(IRepositorio generoRepositorio)
• {
• _generoRepositorio = generoRepositorio;
• }
• [HttpGet]
• public IEnumerable<GeneroDTO> Get()
• {
• return _generoRepositorio.GetAll();
• }

• // GET api/<GeneroController>/5
• [HttpGet("{id}")]
• public GeneroDTO Get(int id)
• {
• return _generoRepositorio.GetGeneroById(id);
• }
• [HttpPost]
• public async Task<GeneroDTO> Post(GeneroDTO genero)
• {
• return await _generoRepositorio.CreateGeneroAsync(genero);
• }

• // PUT api/<GeneroController>/5
• [HttpPut("{id}")]
• public async Task<bool> Put(GeneroDTO genero)
• {
• return await _generoRepositorio.UpdateGeneroAsync(genero);
• }
• [HttpDelete("{id}")]
• public async Task<bool> Delete(int id)
• {
• return await _generoRepositorio.DeleteGeneroAsync(id);
• }
• [HttpPut("{id}")]
• [ActionName(nameof(UpdateProductAsync))]
• public async Task<ActionResult<Products>> UpdateProductAsync(int id,Products product)
• {
• if (id != product.Id)
• {
• return BadRequest();
• }

• await _productRepository.UpdateProductAsync(product);

• return NoContent();
• }
• [HttpDelete("{id}")]
• [ActionName(nameof(DeleteProduct))]
• public async Task<ActionResult<bool>> DeleteProduct(int id)
• {
• var product = await _productRepository.GetProductById(id);
• if (product == null)
• {
• return BadRequest();
• }
• await _productRepository.DeleteProductAsync(product);

• return Ok();
• }
 AZURE DEVOPS GRATIS
• https://dev.azure.com/fabioortizcharris/?acquisitionId=7c1bea87-a028-44d0-9fab-
012f5dadd76f&acquisition=true
 INTRODUCCION A AZURE
• Microsoft Azure (anteriormente Windows Azure y Azure Services Platform) es un
servicio de computación en la nube creado por Microsoft para construir, probar,
desplegar y administrar aplicaciones y servicios mediante el uso de sus centros de
datos. Proporciona software como servicio (SaaS), plataforma como servicio
(PaaS) e infraestructura como servicio (IaaS) y es compatible con
muchos lenguajes, herramientas y marcos de programación diferentes, incluidos
software y sistemas específicos de Microsoft y de terceros.
• Implementación de la aplicación en Azure
• Desde el Explorador de soluciones, haga clic con el botón derecho en el proyecto y
seleccione Publicar.
EN EL CUADRO DE DIÁLOGO PUBLICAR:
SELECCIONE AZURE.
SELECCIONE NEXT (SIGUIENTE).
 EN EL CUADRO DE DIÁLOGO PUBLICAR:
SELECCIONE AZURE APP SERVICE (WINDOWS) .
SELECCIONE NEXT (SIGUIENTE).
EN EL CUADRO DE DIÁLOGO PUBLICAR, SELECCIONE
CREATE A NEW AZURE APP SERVICE (CREAR UNA
INSTANCIA DE AZURE APP SERVICE).
 APARECE EL CUADRO DE DIÁLOGO CREAR SERVICIO DE APLICACIONES:

SE RELLENAN LOS CAMPOS DE ENTRADA NOMBRE DE LA APLICACIÓN, GRUPO DE

RECURSOS Y PLAN DE APP SERVICE. PUEDE MANTENER ESTOS NOMBRES O
CAMBIARLOS.
SELECCIONE CREAR.
 UNA VEZ TERMINADA LA CREACIÓN, EL CUADRO DE DIÁLOGO SE CIERRA
AUTOMÁTICAMENTE Y EL CUADRO DE DIÁLOGO PUBLICAR VUELVE A RECIBIR EL FOCO:
LA NUEVA INSTANCIA QUE SE ACABA DE CREAR SE SELECCIONA AUTOMÁTICAMENTE.
SELECCIONE FINALIZAR.
A CONTINUACIÓN, VERÁ LA PÁGINA DE RESUMEN DEL PERFIL DE
PUBLICACIÓN. VISUAL STUDIO HA DETECTADO QUE ESTA
APLICACIÓN REQUIERE UNA BASE DE DATOS DE SQL SERVER Y LE
PIDE QUE LA CONFIGURE. SELECCIONE CONFIGURAR.
APARECE EL CUADRO DE DIÁLOGO CONFIGURAR DEPENDENCIA:

SELECCIONE AZURE SQL DATABASE.

SELECCIONE NEXT (SIGUIENTE).
 EN EL CUADRO DE DIÁLOGO CONFIGURE AZURE SQL
DATABASE (CONFIGURAR BASE DE DATOS DE AZURE SQL),
SELECCIONE CREAR UNA BASE DE DATOS SQL.
• Aparece el cuadro de diálogo Crear una base de datos de Azure SQL:

• Se rellenan los campos de entrada de datos Nombre de la base de datos, Grupo de recursos,
Servidor de base de datos y Plan de App Service. Puede mantener estos nombres o
cambiarlos.
• Especifique los valores de Database administrator username (Nombre de usuario del
administrador de la base de datos) y Database administrator password (Contraseña del
administrador de la base de datos) del servidor de bases de datos seleccionado (tenga en
cuenta que la cuenta que use debe tener los permisos necesarios para crear la base de datos
de Azure SQL).
• Seleccione Crear.
• Una vez finalizada la creación, el cuadro de diálogo se cierra automáticamente y el cuadro
de diálogo Configure Azure SQL Database (Configurar base de datos de Azure SQL), vuelve
a recibir el foco:

• La nueva instancia que se acaba de crear se selecciona automáticamente.

• Seleccione Next (Siguiente).
• En el paso siguiente del cuadro de diálogo Configure Azure SQL Database (Configurar base
de datos de Azure SQL):

• Rellene los campos Database connection user name (Nombre de usuario de conexión de la
base de datos) y Database connection password (Contraseña de conexión de la base de
datos). Estos son los detalles que utilizará la aplicación para conectarse a la base de datos en
tiempo de ejecución. El procedimiento recomendado es evitar el uso de los mismos detalles
que el nombre de usuario y la contraseña de administrador usados en el paso anterior.
• Seleccione Finalizar.
EN LA PÁGINA DE RESUMEN DEL PERFIL
DE PUBLICACIÓN, SELECCIONE
CONFIGURACIÓN:
• En la página Configuración del cuadro de diálogo Publicar, haga lo siguiente:
• Expanda Bases de datos y active Usar esta cadena de conexión en tiempo de
ejecución.
• Expanda Migraciones de Entity Framework y active Aplicar esta migración al
publicar.
• Seleccione Guardar. Visual Studio volverá al cuadro de diálogo Publicar.
 HAGA CLIC EN PUBLICAR. VISUAL STUDIO PUBLICA LA
APLICACIÓN EN AZURE. CUANDO LA IMPLEMENTACIÓN
TERMINE, LA APLICACIÓN SE ABRE EN UN EXPLORADOR.
• Servicio de aplicaciones de Microsoft Azure: bienvenida (apipeliculas20221120123045.azur
ewebsites.net)
 FRONT END
ANGULAR
• Instalar Angular
• Estructura Proyecto
• Análisis Componentes
• Crear Componentes
• Crear Servicios
• Crear Modelos
• Templates
• Múltiples componentes
• npm install -g latest
• Npm cache –forcé
• npm set audit false
• npm install -g @angular/cli@latest
• Ng new <<Proyect>>