Los patrones de diseño han evolucionado para abordar los problemas que a menudo se encuentran en las aplicaciones de software. Son soluciones a problemas y complejidades recurrentes en el diseño de software. Hemos analizado muchos patrones de diseño aquí, incluido el patrón de especificación, el patrón de unidad de trabajo, el patrón de objeto nulo, el patrón de opciones, el patrón de peso mosca, el patrón de comando, el patrón de intérprete y el patrón singleton. En esta publicación analizaremos Profundice en el patrón de diseño REPR (solicitud-punto final-respuesta), cómo simplifica el desarrollo de API y cómo se puede implementar en C#. Para utilizar los ejemplos de código proporcionados en este artículo, debe tener Visual Studio 2022 instalado en su sistema. Si aún no tiene una copia, puede descargar Visual Studio 2022 aquí. ¿Qué es el patrón de diseño REPR? El patrón de diseño REPR es un enfoque que ayuda a los desarrolladores a mejorar la mantenibilidad, reutilización y extensibilidad del código al aislar las preocupaciones. Los desarrolladores pueden crear API bien estructuradas y fácilmente ampliables concentrándose en la solicitud, el punto final y la respuesta. El patrón de diseño REPR promueve la modularización y garantiza una separación clara entre la solicitud de entrada, la lógica en el punto final y la respuesta de salida. De manera análoga a la arquitectura de corte vertical, el patrón de diseño REPR simplifica el desarrollo de API al organizar sus API en torno a puntos finales en lugar de controladores. Recuerde que el patrón de diseño REPR no se basa en REST ni en recursos. En cambio, es un patrón utilizado para definir los puntos finales de su API. ¿Por qué utilizar el patrón de diseño REPR? El patrón MVC (modelo-vista-controlador) se ha utilizado tradicionalmente para crear puntos finales de API. Si bien el patrón MVC tiene varios beneficios, una de las principales limitaciones de este enfoque son los controladores inflados, también conocido como el «problema del controlador inflado». Esto se debe a que a menudo terminas con controladores que tienen métodos dispares que no son coherentes (nunca se llaman entre sí) y realmente no van juntos. Como resultado, la aplicación se aleja de los métodos basados ​​en REST y termina con una colección vaga de métodos expuestos a través de puntos finales HTTP. El patrón REPR resuelve el problema de la sobrecarga del controlador al eliminar la necesidad de tener múltiples métodos de acción en un solo controlador. En cambio, el patrón REPR se adhiere al principio de responsabilidad única, lo que le permite tener un controlador por acción compatible en un caso de uso típico. Otros beneficios clave incluyen la separación de preocupaciones, una mejor reutilización del código, una mejor legibilidad y mantenibilidad, una mejor capacidad de prueba y una depuración más simple, y una mayor seguridad y escalabilidad. Sin embargo, el patrón REPR también tiene ciertas desventajas. Estos incluyen una mayor complejidad y duplicación de código. Cree un proyecto de API web ASP.NET Core en Visual Studio 2022. Para crear un proyecto de API web ASP.NET Core 8 en Visual Studio 2022, siga los pasos que se describen a continuación. Inicie el IDE de Visual Studio 2022. Haga clic en «Crear nuevo proyecto». En la ventana «Crear nuevo proyecto», seleccione «ASP.NET Core Web API» de la lista de plantillas que se muestran. Haga clic en Siguiente. En la ventana «Configura tu nuevo proyecto», especifica el nombre y la ubicación del nuevo proyecto. Opcionalmente, marque la casilla de verificación «Colocar solución y proyecto en el mismo directorio», según sus preferencias. Haga clic en Siguiente. En la ventana «Información adicional» que se muestra a continuación, seleccione «.NET 8.0 (soporte a largo plazo)» como versión del marco y asegúrese de que la casilla «Usar controladores» esté marcada. Usaremos controladores en este proyecto. En otra parte de la ventana «Información adicional», deje el «Tipo de autenticación» configurado en «Ninguno» (el valor predeterminado) y asegúrese de que las casillas de verificación «Habilitar compatibilidad con Open API», «Configurar para HTTPS» y «Habilitar Docker» permanezcan sin marcar. . No utilizaremos ninguna de esas funciones aquí. Haga clic en Crear. Usaremos este proyecto ASP.NET Core Web API para trabajar con el patrón de diseño REPR en las secciones siguientes. Componentes del patrón de diseño REPR Como sugiere el nombre, el patrón de diseño REPR incluye tres componentes: Solicitud: representa los datos de entrada que el punto final espera. Estos objetos de solicitud deben usarse para la validación de entradas y el paso de datos entre las capas de la aplicación. Punto final: representa la lógica ejecutada por el punto final para una solicitud determinada. Respuesta: Esto representa los datos de salida que devuelve el punto final. Crear un objeto de solicitudEl siguiente fragmento de código ilustra una clase de solicitud típica. clase pública CreateUserRequest { public int UserId { get; colocar; } cadena pública Nombre de usuario { get; colocar; } cadena pública Contraseña { get; colocar; } cadena pública Correo electrónico { get; colocar; } }De manera similar, una clase de solicitud para crear un nuevo producto se vería así: clase pública CreateProductRequest { public int Id { get; colocar; } cadena pública NombreProducto { get; colocar; } categoría de cadena pública { get; colocar; } cadena pública Descripción { get; colocar; } cantidad decimal pública { get; colocar; } Precio decimal público { get; colocar; } }Y una clase de solicitud para recuperar datos del producto se vería así:public class GetProductRequest { public int Id { get; colocar; } cadena pública NombreProducto { get; colocar; } cadena pública Descripción { get; colocar; } Precio decimal público { get; colocar; } }Implemente la lógica en el punto final. Consulte la carpeta Controladores en el proyecto que creó anteriormente. Haga clic derecho en la carpeta Controladores y cree un nuevo controlador API llamado CreateProductController. Reemplace el código generado predeterminado con el siguiente código. Usando Microsoft.AspNetCore.Mvc; espacio de nombres REPR_Example.ProductAPI.Endpoints.Product.CreateProduct {
[Route(«api/[controller]»)]
[ApiController]
clase pública CreateProductController: ControllerBase {
[HttpPost(Name = «GetProducts»)]
[ProducesResponseType(StatusCodes.Status204NoContent)]

public ActionResult GetProductsAsync( GetProductRequest getProductRequest) { //Escriba su código aquí para recuperar productos. devolver Sin contenido(); }
[HttpPost(Name = «CreateProduct»)]
[ProducesResponseType(StatusCodes.Status204NoContent)]

public ActionResult CreateProductAsync (CreateProductRequest createProductRequest) { //Escriba su código aquí para implementar lógica como //validación, mapeo, etc. return NoContent(); } } }Ahora, considere el siguiente punto final HTTP GET. https://localhost:4586/api/getproductsCuando se alcanza este punto final, la respuesta típica en JSON se verá así:{ «products»: [
            {
                  «id»: 1,
                  «name»: «HP ZBook Laptop»,
                  «description»: » i9 Laptop with 32 GB RAM and 1 TB SSD»,
                  «price»: 2500
            },
            {
                  «id»: 2,
                  «name»: «Lenovo Thinkpad Laptop»,
                  «description»: «i9 Laptop with 16 GB RAM and 1 TB SSD»,
                  «price»: 1500
            }
      ]
}Cree el objeto de respuestaPor último, pero no menos importante, el siguiente fragmento de código ilustra una clase de respuesta típica.public class CreateProductResponse { public int StatusCode { get; colocar; } cadena pública ErrorMessage { get; colocar; } } Cabe señalar aquí que no todos los puntos finales necesitarán datos de entrada para las clases de solicitud o respuesta. En muchos casos, es posible que solo necesite enviar el código de estado HTTP en la respuesta. Casos de uso del patrón REPR Un caso de uso típico del patrón REPR es CQRS (segregación de responsabilidad de comandos y consultas), donde necesita tener un punto final separado para cada comando. y consulta. La arquitectura de corte vertical es otro caso de uso del patrón REPR, donde la aplicación se divide en capas verticales según sus responsabilidades. Dicho esto, no está obligado a utilizar REPR para crear un estilo de arquitectura particular. Podría definir recursos RESTful e incluso puntos finales de estilo RPC utilizando el patrón de diseño REPR. Puede decidir optar por este patrón según los requisitos de su aplicación. El patrón de diseño REPR ayuda a mejorar la legibilidad, el mantenimiento y la escalabilidad de su código base aislando las distintas capas de su aplicación, como la interfaz de usuario, la lógica empresarial, y las capas de acceso a datos. Puede modificar y ampliar el patrón REPR según sus requisitos incorporando capas o componentes adicionales. Copyright © 2024 IDG Communications, Inc.

Source link