JSF 스캐(스크린캐스팅)를 찍다가 알게 된건데, 기본 검증기, Application-level 검증, 커스텀 검증기, 표준 검증기가 있었습니다.

기본 검증기는 프레임워크에서 제공하는 것으로 JSF에는 길이 검사라던가, 숫자가 최소치와 최대치 사이의 값인지 범위를 검사할 수 있는 기본 Validator들을 제공하고 있었습니다. 스프링 MVC는 어떨까요? 글쎄요. 없는 것 같네요. ValidationUtils는 있지만 JSF 처럼 간단하게 뷰에서 바로 써먹을 수 있는 건 없는 것 같습니다.

다음은 폼에서 이미 검증을 마쳐서 모델에 사용자가 입력한 데이터를 담은 상태로 비즈니스 로직을 검사하는 검증입니다. 이 검증은 프레임워크에 독립적이며 도메인 클래스가 해당 로직을 가지고 있기도 합니다. 예를 들어.. member.validateBy주민번호() 같은 메소드(주민등록 번호로 성별과 생년 월일이 일치하는지 검사하는 로직)를 만들고 이를 컨트롤러에서 호출한 다음에 예외를 잡아서 화면에 어떤 에러 메시지를 출력하는 방법이 있겠습니다. 비즈니스 로직에 적합한지 검사하려면 역시 화면에 붙어있는 검증기와는 별개로 이런게 필요한 것 같습니다. 스프링MVC에서도 검증 로직이 순전히 도메인 레벨에서 가능하다면 이런 식으로 검증할 수도 있겠습니다.

다음은 검증기는 검증기인데, 특정 인터페이스를 따르지도 않고 완전한 POJO 검증기 입니다. 위에서 애플리케이션 검증 로직을 별도의 클래스로 빼내고 그 로직을 뷰에서 값을 입력 받을 때 호출하게 하는 건데, JSF의 EL은 메소드 호출도 정말 간단하게 할 수 있더군요. 그냥 이런 검증기를 managed-bean으로 등록하고 그 로직을 호출하면 됐습니다. 검증 로직을 별도의 클래스로 분리하고 한 곳에서 관리할 때 좋겠습니다.

마지막은 스프링이 제공하는 Validator인터페이스 처럼 프레임워크의 틀에 맞는 검증기를 구현하고 그것을 설정하여 사용하는 겁니다. JSF에도 그런 구조가 갖춰져 있죠. 이 걸 사용하는 장점은 어떤 틀이 있기 때문에 위처럼 중구 난방으로 작성할 수 있는 코드에 규약을 정하고 그걸 따르는 검증기를 공유할 수 있다는 겁니다. JSF는 스프링 @MVC와 달리 이 검증 로직 실행을 프레임워크의 Phase 중에서 Validation Phase에 하기 때문에 이 검증 로직을 만족하지 못하면 모델에 값이 들어갈 수가 없습니다. 스프링은 아니죠. 일단 모델에 값을 받은 상태에서 검증을 하는거죠.

흠~~ 그래서 결론적으로 생각해볼 때, 여러 검증 단계와 방법을 제공하는 건 JSF가 더 좋아보이지만, 모델에 값을 설정한 상태에서 Validator라는 규격을 가지고 그 안에서 비즈니스 로직 검사도 수행(application-level 검증)도 할 수 있는.. 스프링 MVC의 단순한 구조가 오히려 개발을 더 깔끔하게 할 수 있게 해주지 않나 생각합니다. 모든 개발자가 검증 로직을 사방한대서 한다고 생각하면.. 어휴.. 끔찍하죠.ㅋㅋ