Gosto do ponto de extensibilidade do MVC, permitindo que os modelos de visualização implementem IValidatableObject e adicione validação personalizada.
Eu tento manter meus controladores magros, tendo esse código como a única lógica de validação:
if (!ModelState.IsValid)
return View(loginViewModel);
Por exemplo, um modelo de visualização de logon implementa IValidatableObject, obtém o objeto ILoginValidator via injeção do construtor:
public interface ILoginValidator
{
bool UserExists(string email);
bool IsLoginValid(string userName, string password);
}
Parece que o Ninject, injetar instâncias nos modelos de exibição não é realmente uma prática comum, pode até ser um anti-padrão?
Será esta uma boa abordagem? Existe um melhor?
Respostas:
Pessoalmente, para mim, seu design parece limpo.
IValidatableObject significa que o modelo de exibição fornecerá alguma validação que não pode ser fornecida por atributos simples - injetando o validador real que chamará serviços / bancos de dados / o que mantém seu design limpo e garante que você não viola o princípio da responsabilidade única - os modelos de exibição são responsável, essencialmente, pela transferência e validação dos dados transferidos (seja por meio de atributos ou IValidatableObject ou ambos).
fonte
Ter um objeto dedicado para validação garante que você realmente respeite o SRP - o que já era o caso, pois é uma responsabilidade típica de um modelo de exibição validar seus dados.
Quanto à injeção de instâncias nos modelos de exibição, não vejo nada de errado nisso. Praticamente não há limite para o que pode ser injetado no quê.
fonte
Em vez de injetar o ILoginValidator no construtor da VM, você pode usar o ValidationContext (que é o argumento para IValidatableObject.Validate ()) para obter seu validador.
fonte