Me gusta el punto de extnesibilidad de MVC, que permite ver modelos para implementar IValidatableObject y agregar validación personalizada.
Intento mantener mis controladores esbeltos, teniendo este código como la única lógica de validación:
if (!ModelState.IsValid)
return View(loginViewModel);
Por ejemplo, un modelo de vista de inicio de sesión implementa IValidatableObject, obtiene el objeto ILoginValidator a través de la inyección del constructor:
public interface ILoginValidator
{
bool UserExists(string email);
bool IsLoginValid(string userName, string password);
}
Parece que Ninject, inyectar instancias en modelos de vista no es realmente una práctica común, ¿puede ser incluso un antipatrón?
¿Es este un buen enfoque? Hay alguno mejor?
Respuestas:
Personalmente, para mí tu diseño parece limpio.
IValidatableObject significa que el modelo de vista proporcionará una validación que no puede ser proporcionada por atributos simples: inyectando el validador real que llamará a servicios / bases de datos / lo que sea que mantenga su diseño limpio y garantice que no viole el principio de responsabilidad única: los modelos de vista son responsable, esencialmente, de transferir datos y validar los datos que se transfieren (ya sea a través de atributos o IValidatableObject o ambos).
fuente
Tener un objeto dedicado para la validación garantiza que usted respeta SRP de hecho, lo cual ya era el caso de todos modos ya que es una responsabilidad típica de un modelo de vista validar sus datos.
En cuanto a la inyección de instancias en los modelos de vista, no puedo ver nada malo en eso. Prácticamente no hay límite a lo que se puede inyectar en qué.
fuente
En lugar de inyectar el ILoginValidator en su constructor de VM, puede usar ValidationContext (que es el argumento de IValidatableObject.Validate ()) para obtener su Validator.
fuente