c# - framework - ¿Cómo hacer que la configuración de Fluent API funcione con la validación del lado del cliente MVC?

hascolumntype example

Question

Prefiero trabajar con la configuración de Fluent API a DataAnnotation porque quiero separar el modelo del acceso a los datos.

He intentado en MVC, Fluent API no funciona con la validación del lado del cliente. En pocas palabras, ¿existe una forma sencilla de hacer que Fluent API funcione con la validación del lado del cliente como puede hacer DataAnnotation?

Answer 1

Luché con esto por un tiempo hoy, y esto no es estrictamente la validación del cliente, ya que requiere un viaje de ida y vuelta, pero te permite beneficiarte del resumen de validación y los mensajes de ayuda en la plantilla estándar. Dentro del método de acción de su controlador, simplemente envuelva su llamada SaveChanges() en un try-catch y agregue los errores resultantes al ModelState siguiente manera:

try {

    //This does not pick up fluent validation failures
    if (ModelState.IsValid) {
        db.Entity.Add(entity);
        db.SaveChanges();
        //Users want to create loads of my entities without seeing the index...
        return RedirectToAction("Create");
    }

} catch (DbEntityValidationException e) {

    //Log errors
    foreach (var result in e.EntityValidationErrors) {
        foreach(var error in result.ValidationErrors){
            ModelState.AddModelError(error.PropertyName, error.ErrorMessage);
        }
    }

}

//return to view with current model + validation errors 
return View(entity)

Por supuesto, esto requeriría un poco más de trabajo si está guardando varias entidades aquí.

Por supuesto, usar los objetos de un Modelo de Vista como lo sugiere Ladislav sería el enfoque correcto, sin embargo, lo he usado para respaldar una IU de prueba solicitada para las pruebas de integración de sistemas posteriores antes de lo programado ...

Answer 2

No. Fluent API es solo mapeo - correcto Las anotaciones de datos son mapeo y validación, incorrectas. Las anotaciones de datos son una de las peores características del código EF en primer lugar porque cuando se usan de esta manera, combinan la persistencia con la lógica de presentación y validación.

Consejo: no utilizar entidades EF para la presentación. Use modelos de vista especiales con anotaciones de datos y deje que su controlador prepare modelos de vista de entidades y viceversa. Pronto o más adelante encontrará situaciones en las que su validación no es 1: 1 con su asignación o donde su vista necesita más o menos datos que los proporcionados en el tipo de entidad. Usa modelos de vista y estas situaciones serán manejadas por ellos.