스프링 폼 명령의 의도

Question

스프링 폼 컨트롤러 (예 : SimpleFormController 또는 BaseCommandController)는 명령을 사용하여 HTML 양식과 컨트롤러간에 데이터를 전달합니다. 제 질문은, 지원 모델을 명령 자체로 사용하는 것이 일반적인 관행입니까? 또는 지원 모델의 속성에 해당하는 속성을 가진 별도의 명령을 만드는 것이 일반적입니다.

제 문제는 문자열 형식이 아닌 속성을 변환 할 때 속성 편집기가 필요하다는 것입니다. 많은 문자열이 아닌 강하게 입력 된 사용자 정의 필드 유형이있는 데이터 모델을 상상해보십시오. 양식 제출시, 특성 편집기는 유효성 검사기가 호출되기 전에 변환을 수행합니다. 형식 변환이 불가능한 경우 (사용자 입력 오류) 유효성 검사기는 자세한 오류 메시지를 제공 할 기회를 얻지 못합니다. HTML 양식에 표시된 것은 모두 일반적인 오류 메시지입니다. 내 related Stackoverflow question을 참조하십시오.

대체 방법은 지원 모델의 각 필드를 복제하는 별도의 명령을 문자열로 작성하는 것입니다. 이렇게하면 유효성 검사기는 각 필드의 문자열 표현을 검증 할 수 있습니다. 컨트롤러의 onSubmit은 텍스트 기반 명령을 백업 모델로 변환합니다. 스프링에 대한 나의 연구에서 이것은 의도 된 사용법 인 것으로 보인다. 이 길을 걷는 것을 주저하는 것은 각 데이터 모델에 대해 별도의 명령을 작성해야하는 번거로운 방식입니다. 그런 다음 명령과 데이터 모델을 마샬링해야하는 추가 작업이 있습니다. 양식을 직접 백업 모델을 편집하고 속성 편집기를 사용하여 변환하는 것이 훨씬 더 편리합니다. 그러면 문제는 유효성 검사입니다.

다른 사람들이 사용자 정의 형식의 비 문자열 필드를 포함하는 모델의 양식 기반 편집 문제에 어떻게 접근하는지 궁금합니다.

Answer 1

Spring binding and validation API을 살펴 보시기 바랍니다. 서비스 레이어가 필요로하는 객체에 폼 요소를 바인딩하고 컨트롤러가이를 전달하게합니다.

내가 선호하는 것은 비즈니스 개체에 직접 바인딩하고 웹 계층을 위해서만 DTO를 만들지 않는 것입니다. 나는 평행 계층을 좋아하지 않는다.

Answer 2

IMHO는 도메인 클래스를 어떻게 디자인 할 것인가에 달려 있습니다. 나는 심지어 값을 설정하는 것을 허용하지 않음으로써 qiute strict를 디자인하는 것을 선호한다. 이것은 Spring이 바인딩과 유효성 검사를 처리하는 방식과 잘 결합되지 않는다.

내 도메인 모델의 약화를 피하려면 일반적으로 DTO를 명령 개체로 사용하는 경향이 있습니다. 일반적으로 프레젠테이션은 도메인 개체에 대해 약간 다른보기를 얻습니다. 고전적인 예는 암호를 운반하는 사용자 도메인 클래스입니다. 프리젠 테이션 계층에서는 일반적으로 실제 사용자에게 암호를 두 번 입력하고 유효성 검사 단계에서이 값을 비교하려고합니다. 일치하는 경우에만 데이터가 도메인 클래스에 바인딩됩니다.

약간의 오버 헤드가 있지만 도메인/응용 프로그램 계층을보기에서 완전히 분리 할 수 ​​있습니다.