IValidatableObject 대 단일 책임

뷰 모델이 IValidatableObject를 구현하고 사용자 지정 유효성 검사를 추가 할 수있는 MVC의 확장 성 지점이 마음에 듭니다.

이 코드가 유일한 유효성 검사 논리가되도록 컨트롤러를 간결하게 유지하려고합니다.

if (!ModelState.IsValid)
    return View(loginViewModel);

예를 들어, 로그인 뷰 모델은 IValidatableObject를 구현하고 생성자 삽입을 통해 ILoginValidator 객체를 가져옵니다.

public interface ILoginValidator
{
    bool UserExists(string email);
    bool IsLoginValid(string userName, string password);
}

뷰 모델에 인스턴스를 주입하는 Ninject는 실제로 일반적인 관행이 아니며 안티 패턴 일 수도 있습니까?

이것이 좋은 접근입니까? 더 좋은 것이 있습니까?

개인적으로 당신의 디자인은 깨끗해 보입니다.

IValidatableObject는 뷰 모델이 단순한 속성으로는 제공 할 수없는 몇 가지 검증을 제공함을 의미합니다. 서비스 / 데이터베이스를 호출하는 실제 유효성 검사기를 주입합니다. / 디자인을 깨끗하게 유지 하고 단일 책임 원칙을 위반 하지 않는 모든 것-뷰 모델은 본질적으로 데이터를 전송하고 전송 된 데이터의 유효성을 검사 할 책임이 있습니다 (속성 또는 IValidatableObject 또는 둘 다를 통해).

유효성 검사를위한 전용 개체를 보유하면 실제로 SRP를 존중할 수 있습니다. 이는 데이터를 유효성 검사하는 뷰 모델의 일반적인 책임이기 때문에 이미 그랬습니다.

뷰 모델에 인스턴스를 주입하는 것에 대해서는 잘못된 점이 없습니다. 실제로 무엇을 주입 할 수 있는지에 대한 제한은 없습니다.

VM 생성자에 ILoginValidator를 주입하는 대신 ValidationContext (IValidatableObject.Validate ()의 인수)를 사용하여 유효성 검사기를 가져올 수 있습니다.

public IEnumerable<ValidationResult> Validate(ValidationContext vc)
{

var loginValidator = (ILoginValidator)vc.GetService(typeof(ILoginValidator));
return loginValidator.Validate();

}