자바단에서의 유효성검사

안녕하세요. @Valid 를 사용하면 간단하게 유효성 검사를 할 수 있어서 유용하죠. 하지만 말씀하신 것처럼 보다 다양한 케이스를 대응하려면 다른 방식이 필요합니다. 첫 번째로는 Custom Validator를 작성하여 사용하는 방법입니다. 예를 들어, name과 age 필드를 가진 User 라는 클래스가 있을 때, UserValidator 를 생성 후, name과 age 를 모두 유효성 검사하는 로직을 추가할 수 있습니다. Custom Validator 를 사용하는 방법은 (a) 직접 validator 를 사용하거나, (b) InitBinder Annotation을 사용하거나 (c) WebMvcConfigurer 설정을 통해 등록하여 사용할 수 있습니다. Custom Validator를 사용하면 단점은 유효성 검사 로직이 클래스 단위로 독립적이라 여러 곳에서 재 사용이 어려울 수도 있습니다. 두 번째로는 AOP(Aspect-Oriented Programming)를 이용하는 방법입니다. Aspect 클래스를 정의하고, 비즈니스로직을 태우기 전 메서드 등에 Custom Annotation 을 추가하여 유효성 검사를 할 수 있습니다. 이는 어느 정도 코드의 중복을 줄일 수 있고, 유효성 검사 로직을 한 곳에서 관리할 수 있다는 장점이 있습니다. 다만 AOP를 이해하고 있어야 하며, 디버깅이 다소 어려워질 수 있습니다. 세 번째로는 Chain Responsibility 패턴을 이용해 복잡한 유효성 검사를 여러 단계로 나눠서 처리하는 방법입니다. 각 단계는 자신이 확인해야 하는 유효성을 체크한 뒤 다음 단계로 넘기는 식으로 구현하는 것이죠. 각 단계의 로직이 분리되어 확정성이 좋은 편이며, 단점으로는 다른 방법에 비해 설계가 복잡할 수 있으며, 여러 검증 단계를 거치므로 실행 시간이 상대적으로 늘어날 수 있습니다. 이처럼 다양한 유효성 검사 방법을 살펴보았는데요. 경험상 유효성 검사는 프로젝트 초기에는 신경을 많이 쓰지만 시간이 지날수록 느슨해지는 지기도 하며, 또한 정반대로 초기에는 유효성 검사가 거의 없다가 요구 사항의 증가로 계속 추가되기도 합니다. 따라서 유효성 검사 로직과 그 프로세스는 모든 프로젝트 멤버가 접근하기 쉬운 코드나 방식으로 구성하는 것이 유리하며, 디버깅과 테스트가 용이해야 일관성 있는 유효성 검사가 유지되는 것 같습니다.

ㅋㅋㅋㅋ 사실 유효성을 확인에 대해서 많은 사람들이 비즈니스로직 전이라고 생각을 하지 않고 약간 무시하지만 결국 유지보수할 때 손이 젤 많이 가능 부분 중의 하나가 유효성 확인입니다. 또한 DB를 뒤져서 유효성하는 경우는 사실 많은 비즈니스 로직을 포함할 경우가 많습니다. 유효성을 체크할 수 있는 방법은 아래 분이 잘 설명을 주신 것 같아서 또 언급하지는 않아도 될 것 같습니다. 저는 유효성의 성격에 따라 분리하는 것에 대해서 이야기하고 싶습니다. - 형식 체크 : not null 등 JSR-380을 이용해서 할 수 있는 부분은 데이터가 프로그램에 들어오는 시점에서 하는 것을 권합니다. 아마도 Controller 단이 될 것 같습니다. 이 부분에서 주의해야 하는 것은 비즈니스 로직이 있으면 안된다는 것입니다. not null, email.... 이런 것만 체크하고 - 비지니스 로직 유효성 확인 : 예를 들어 사람의 나이는 숫자여야 한다는 위에서 사람의 나이는 150살을 넘을 수 없다는 유효성이 아니라 business rule 이고 이것이 표현되고 구현되어야 하는 장소는 domain 로직입니다. DDD에서는 이런 부분은 Aggregate의 invariant라고 하기도 합니다. 암튼 비즈니스에서 깨지지 않아야 하는 룰은 domain 객체에서 가지고 있어야 합니다. 때문에 Person.ageValidate()로 구현이 되어야 합니다. 둘을 분리하신다면 도움이 좀 되지 않을가 생각이 됩니다.