¿Deben los validadores en primavera acceder a la base de datos?

Question

No estoy seguro de si es una buena decisión de diseño hacer que los validadores validen los comandos según el estado de la base de datos. Por ejemplo, si necesito validar un bean de usuario además de verificar si el correo electrónico y el nombre de usuario están vacíos, etc. También debo rechazar los valores si ya los he usado. ¿Debería este tipo de lógica entrar en los validadores o en los objetos de servicio?

Answer 1

Bueno, sus validadores son simplemente granos de primavera, a la derecha, para que puedan ser inyectados con los objetos de servicio que manejan el acceso a los datos. Puede hacer que sus validadores obtengan datos de la base de datos sin comprometer el diseño.

Answer 2

no, los validadores en mi humilde opinión deben ser pequeños y side-effect free para que se puedan combinar fácilmente. Definitivamente, un validador debe estar desacoplado de la capa de persistencia.

Answer 3

comprobado que una de las minas y llamo a la capa de servicio desde el validador:

@Service 
public final class StartFormValidator { 
private FacilityService facilityService; 
private AdminService adminService; 

/** 
* Verify that they've selected a facility. Verify that they've selected a 
* valid facility. Verify that they've selected a view and that it's a valid 
* view. 
* 
* @param startForm 
* @param errors 
* @return true if no errors were set 
*/ 
public boolean isValid(final StartForm startForm, final Errors errors) { 
    if (startForm.getFacilityId() == 0) { 
     errors.rejectValue("facilityId", "facilityIdEmpty", 
       "Select a facility."); 
    } 

    if (!this.facilityService.isFacilWaitlistEnabled(startForm 
      .getFacilityId())) { 
     errors.rejectValue("facilityId", "facilityInvalid", 
       "Invalid facility"); 
    } 

    if (StringUtils.isBlank(startForm.getPassword())) { 
     errors.rejectValue("password", "passwordEmpty", 
       "Enter the password."); 

     return (false); 
    } 

    if (!this.adminService.validateAdmin(startForm.getPassword())) 
     errors.rejectValue("password", "passwordInvalid", 
       "Incorrect password"); 

    return (!errors.hasErrors()); 
} 

/** 
* @param _facilityService 
*/ 
@Autowired 
public void setFacilityService(final FacilityService _facilityService) { 
    this.facilityService = _facilityService; 
} 

/** 
* @param _adminService 
*/ 
@Autowired 
public void setAdminService(final AdminService _adminService) { 
    this.adminService = _adminService; 
} 

}

Answer 4

Eso dependerá mucho de cómo se defina la validación. Considere esto: está comprando algo e ingresa su número de tarjeta de crédito. Si el dígito de verificación no coincide, ha fallado la validación. No se ha intentado ninguna transacción. Sin embargo, si es un número de tarjeta de crédito válido, pero no coincide con el código postal (se requiere interacción de DB/terceros), entonces se trata de un error de pago.

Considere esto: Usted está introduciendo su dirección e ingresa a Mastiffica como su país. ¿Por qué el sistema incluso le permitió ingresar esto? Debieron haber restringido la interfaz solo a las entradas válidas (no se necesita entrada de DB).

O ingrese "cincuenta" en el campo de importe de la pantalla de pago de su banco. ¿Por qué permite letras allí? Eso falla validación (No hay necesidad de DB). Pero luego ingresa 50 en el campo de cantidad, y resulta que no tiene cincuenta libras en su cuenta. ¿Es eso un error de validación? ¿O es una transacción fallida?

Ahora, considere que ha pasado todas las validaciones de entrada básicas (suma de comprobación de tarjeta de crédito, país, dígitos, código postal) y la transacción falla, porque su tarjeta de crédito ha expirado. ¿Es ese error de validación o una transacción fallida?

Puede pensar en la validación como una garantía básica de que los usuarios no ingresarán datos completamente desordenados, o puede pensar en la validación como "puedo completar esta transacción con los datos que me han dado". Yo personalmente preferiría lo primero, pero nuevamente, es cuestión de definición.

Luego está el aspecto de la validación de primera línea como medida de seguridad - los datos salvaje que ha sido aceptado más allá de su capa de interfaz de usuario de la parte superior puede ser un riesgo para la seguridad (inyección de SQL, por ejemplo)

Answer 5

Si realmente cree en "MVC "entonces no lo creo, quiere que sus validadores vayan a la base de datos. La validación es una fase que esencialmente valida los datos desde el punto de vista de la lógica de negocios.

La base de datos no necesita saber cómo los validadores la usarán, ni los validadores deberían saber cómo es la base de datos. Eso simplemente no encaja en el modelo MVC. Mañana, si tiene datos provenientes de múltiples fuentes, ¿seguirá adelante y le dirá a sus validadores a qué fuente en particular debería acceder en qué condiciones? Eso mismo constituirá una lógica que ni siquiera es necesaria. en aplicación.

El tipo de validación que está buscando se considerará como parte de los objetos comerciales que garantizarían que incluso antes de llamar a los objetos del servicio; tal combinación no existe ya.

Los objetos de servicio tampoco deben contener validaciones comerciales, por lo que tampoco pertenecen a los validadores ni a los objetos de servicio. Pero sí, si la aplicación es lo suficientemente pequeña como para no preocuparse por demasiadas capas, un enfoque sesgado está bien, pero solo mientras "se siga como un estándar durante todo".

En resumen, creo que los validadores de primavera están destinados a validaciones básicas y no a validaciones comerciales.

Answer 6

prefiero la validación que está utilizando la base de datos debido a la usabilidad del usuario final.

Al enviar un formulario de registro, desea verificar si el nombre de usuario es sintácticamente correcto y si este nombre de usuario no se ha proporcionado (se necesita acceso a la base de datos).

El formulario puede regresar con todos los errores a la vez. Puede mostrar al usuario todos los problemas. El usuario puede arreglarlo y enviar el formulario nuevamente.

Sé que puedes hacerlo de manera más inteligente con ajax y demás, ese no es el punto.

Siempre compruebo todo. Verifico si este formulario será manejado por la próxima transacción. Si no, recibo una excepción debido a algún acceso concurrente que se puede manejar fácilmente.