c# - pages - mvc visual studio 2017

¿Cómo estructurar la validación de datos en.NET Core web API?

Question

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 backend

Hay una serie de puntos finales que siguen esta estructura. La mayoría de las API son puramente consultas de datos a un back-end, pero algunas de las API también permiten que el cliente llamante envíe datos.

Lo que estoy luchando 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 de Controlador fuera muy simple y entregara todo el "trabajo" real (incluida la validación) a la capa de Servicios, y la capa de 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, la mejor forma 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 el servicio / acceso a datos WRT lectura / escritura, etc.

Algunas ideas sobre las que he reflexionado:

• Haga que la capa de servicios conozca la interfaz IActionResult y sea responsable de determinar qué devolver al cliente que realiza la llamada. Esto mezcla el controlador y la capa de servicio, pero hace que la capa del controlador sea bastante delgada.

• Cree varios objetos "OperationResults" para las diversas llamadas de Servicios que encapsularían los mensajes de error, excepciones, códigos de error, etc., para que la capa Controller los interprete para determinar qué respuesta http enviar al cliente. Esta es una separación más limpia ya que la capa de Servicio no se mezcla con el código http, pero luego convierte las clases de Controlador en un gran conjunto de conmutadores para determinar qué enviar.

• Dividir la validación según lo que tenga sentido capturar en el nivel Controlador vs. Servicios. Por ejemplo, un controlador al que se pasa un objeto nulo para guardar debe rechazarlo y devolver BadRequest (), pero parece redundante agregar el cheque allí cuando la capa de servicios tenga sus propias razones para querer verificar eso también.

Estoy seguro de que soy algo nuevo en .NET web API y .net core en general, así que si hay alguna funcionalidad obvia disponible que no estoy aprovechando, me encantaría saber.

Cualquier consejo sería apreciado, gracias.

Answer 1

La idea principal es correcta: debe separar los flujos normales y de error en su código. Uno de los principales enfoques es usar las excepciones .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 acciones específicas por acción. Ver la sección Filtros en la documentación.

• Durante la ejecución de la acción del controlador, debe plantear excepciones tan pronto como sea posible y detener la ejecución posterior. Y sí, la excepción puede plantearse en cualquiera de los niveles (capa de servicio / negocio, capa DA, etc.).

¿Cómo manejar la excepción planteada?

Utilizando los métodos de manejo de errores de ASP.NET Core (como ExceptionHandler, o Exception Filters), puede analizar excepciones y generar respuestas apropiadas / diferentes en consecuencia. Consulte el manejo de errores de SO relacionado en ASP.NET Core 1.0 Web API (Enviar ex.Message al cliente) pregunta por ejemplo. También está la sección de manejo de errores en la documentación.