Tengo una API web asp.net Core con la siguiente estructura:
View Layer: API endpoints | V Controller Layer: Controller classes implementing endpoints | V Business Logic Layer: Services | V Data Access Layer: Proxy classes to our backendHay una serie de puntos finales que siguen esta estructura. La mayoría de las API son puramente consultas de datos a un backend, pero algunas de las API también permiten que el cliente que llama envíe datos.
Lo que me cuesta es encontrar una manera limpia de consolidar las diversas validaciones que deben ocurrir en estos datos enviados.
Mi intención original era que la capa del controlador fuera muy simple y pasara todo el "trabajo" real (incluida la validación) a la capa de servicios, y la capa del controlador solo sería responsable de enviar la respuesta HTTP adecuada. Mi problema, sin embargo, es que con el servicio haciendo todo el trabajo real, cuál es la mejor manera de comunicarle al controlador lo que debería devolver.
Puedo capturar algunas de las validaciones básicas usando anotaciones de datos y, en la mayoría de los casos, eso podría ser suficiente en términos de validación de datos. Pero eso no cubre otros problemas como validaciones más complejas o fallas en la lectura/escritura WRT de la capa de servicio/acceso a datos, etc.
Algunas ideas que he reflexionado:
Haga que la capa de servicios conozca la interfaz IActionResult y hágala responsable de determinar qué devolver al cliente que llama. Esto luego mezcla la capa del controlador y el servicio, pero hace que la capa del controlador sea bastante delgada.
Cree varios objetos "OperationResults" para las diversas llamadas de servicios que encapsularían cualquier mensaje de error, excepciones, códigos de error, etc., para que la capa del controlador los interprete a fin de determinar qué respuesta http enviar al cliente. Esta es una separación más clara ya que la capa de servicio no se mezclaría con el código http en absoluto, pero luego convierte las clases de controlador en un gran conjunto de conmutadores para determinar qué devolver.
Divida la validación en función de lo que tenga sentido capturar en el nivel de controlador frente a servicios. Por ejemplo, un controlador al que se le pasa un objeto nulo para guardar claramente debería rechazarlo y devolver BadRequest(), pero parece redundante agregar la verificación allí cuando la capa de servicios también tendría sus propias razones para querer verificar eso.
Es cierto que soy un poco nuevo en .net web API y .net core en general, por lo que si hay alguna funcionalidad obvia disponible que no estoy aprovechando, me encantaría saberlo.
Cualquier consejo sería apreciado, gracias.
La idea principal es correcta: debe separar los flujos normales y de error en su código. Uno de los enfoques principales es utilizar las excepciones de .NET para indicar que el flujo normal no es posible.
Para la validación de entrada, use ActionFilter . Puede tener filtros globales para todos los controladores o definir específicos por acción. Consulte la sección Filtros en la documentación.
Durante la ejecución de la acción del controlador, debe generar excepciones lo antes posible y detener la ejecución posterior. Y sí, la excepción puede generarse en cualquiera de los niveles (capa de servicio/negocio, capa DA, etc.).
¿Cómo manejar la excepción planteada?
Con los enfoques de manejo de errores proporcionados por ASP.NET Core (como ExceptionHandler o Exception Filters), puede analizar las excepciones y generar respuestas apropiadas/diferentes en consecuencia. Consulte la pregunta relacionada con el manejo de errores de SO en ASP.NET Core 1.0 Web API (envío de un mensaje externo al cliente) , por ejemplo. También existe la sección de manejo de errores en la documentación.