2009-03-18 8 views
4

이 질문은 주로 다른 언어와 프레임 워크에 적용되지만 PHP의 젠드를 대상으로합니다. 그래서 모든 사람의 의견을 환영합니다.양식 객체 또는 모델에서 유효성 검사를 수행해야합니까?

저는 최근에 Zend 프레임 워크를 사용 해왔고 완벽하지는 않지만 꽤 즐거운 시간을 가졌습니다. 그러나 나를 미치게 만드는 한 가지는 젠드를 사용하는 사람들이 보는 대부분의 예제가 모델이 아닌 v alidation in special form objects을 수행한다는 것입니다. 데이터가 양식 입력 이외의 다른 방법으로 시스템에 입력 될 수 있기 때문에 이것은 나쁜 습관이라고 생각합니다. 즉, 다른 입력을 확인하기 위해 유효성 검사기를 구부리거나 꼬아 야하거나 유효성 검사를 두 번째 장소에서 수행해야하고 논리가 복제되어야 함을 의미합니다.

내가하고있는 것과 같은 느낌을 가진 사람들과 함께 다른 게시물과 블로그를 찾았지만 Zend 개발자가 이유를 선택하여 다른 사람이 문제없이 사용하는 것처럼 보였으므로 여기에서 커뮤니티의 의견을 얻으십시오.

내가 말했듯이 이것은 주로 Zend에 적용되지만 Zend 프레임 워크의 경계 내에서 작업하는 것이 아니라 전체적으로 이슈를 조사하는 것이 중요하다고 생각하지만 젠드는 많은 것을 사용할 수 있도록 설계되었습니다. , 또는 조금이라도, 당신이 원했던 것처럼.

답변

3

이것은 비정상적인 답이지만, 모델이 자체 데이터의 유효성을 책임 져야한다고 생각합니다. 이 경우 유효성 검증은 모델에 속하지만, 이는 항상 성취 할 수있는 것은 아니며 뷰에서 유효성 검사를 수행해야 할 수도 있습니다. 그러나 이것은 대체 모델이 아닌 모델에서 수행 된 유효성 검증에 추가되어야한다고 생각합니다 그것을 위해.

보기에서 유효성 검사 만하는 문제는 어느 시점에서 데이터에 대한 다른보기가 필요할 것이라는 점입니다. 귀하의 사이트가 인기를 얻고 고객이 XML 기반 API를 요청하여 자신의 견해를 생성 할 수 있습니다. 그런 다음 고객의 데이터 검증을 의지합니까?

API를 제공 할 필요가없는 경우에도 완전히 다른 버전의 페이지를 보증 할만큼 충분히 다른 사용자 정의 된보기가 필요할 수 있습니다. 이제 복제 된보기에서 유효성을 검사하게됩니다.

이상적인 시나리오는 모델에서 유효성 검사를 수행하는 것이지만 유효성 검사 결과를 볼 수있는 유효성 검사 결과가 표시된 페이지를 다시 읽고 렌더링하는 것입니다.

사용자에게 유효성 검사 데이터를 즉시 표시하고 싶지만 데이터 유효성에 대한 최종 결정이 모델에 있어야한다고 생각하면 유효성 검사를 수행하는 것이 매우 합리적이라고 생각합니다.

0

저는 Zend를 알지 못합니다. 그러나.

모델에 유효한 데이터가 있어야합니다. 모델과 그것의 메서드는 데이터를 몇 번이고 다시 검사해서는 안됩니다. 물론 실제 유효성 검사를 수행하는 함수가 있어야하며 gui 유효성 검사 또는 다른 데이터 입력 위치에서 호출해야합니다.

모델 측에서 할 수있는 최선의 방법은 모든 데이터에 대해 "어설 션"을 호출하여 개발이 유효성 검증을 대신하게되었는지 확인하는 것입니다.

낮은 수준의 코드 (UI, 모델, 유틸리티)는 유효성 검사 및 검사 코드가 적을수록 좋습니다. 그 때 동일한 검증이 더 많이 호출 될 큰 기회가 있습니다.

3

글쎄, 유효성 검사는 다양한 수준에서 수행 할 수 있으며 대개 어느 것도 "최고"입니다. 물론 모델에는 양식에서 가져온 유효하지 않은 데이터로 채울 수 있지만 데이터가 어떤 모델에도 적용되지 않는 양식을 작성할 수도 있습니다.

또한 모델의 직접 유효성 검사는 비영리적으로 양식 렌더링 시스템과 통합되지 않으므로 오류 메시지를 표시하고 사용자가 입력 한 데이터로 양식을 다시 채우려면 문제가 발생합니다.

두 가지 솔루션에는 각각 장단점이 있습니다. 유효성 검사가 마침내 일정 수준에서 완료되어야한다는 것을 보장하는 시스템을 갖추는 것이 이상적입니다. 양식이 일부 데이터의 유효성을 검사하지 않으면 모델이 수행하고 그 반대의 경우도 마찬가지입니다. 불행히도, 나는 그러한 라이브러리에 대해 들어 보지 못했지만 프레임 워크의 유효성 검사기는 언젠가 소스에 독립적이라는 점에 유의해야합니다. POST 데이터를 전달할 수는 있지만 올바르게 구문 분석 된 CSV, MYSQL 데이터베이스 등에서 가져온 정보로도 동일하게 수행 할 수 있습니다.

3

응용 프로그램과 관련된 데이터 유효성 검사는 데이터베이스 스키마와 관련된 데이터 유효성 검사와 항상 동일한 작업입니다.

사용자가 사용자 이름과 암호로 계정을 만드는 간단한 등록 양식을 고려해보십시오. 길이가 X 자이고 문자 유형 (또는 기타)이 혼합되어 있기를 원하기 때문에 암호에 대한 유효성 검증을 수행합니다.

그러나 일반 텍스트 암호를 저장하지 않으므로 데이터베이스 삽입에 대한 데이터 유효성 검사와 관련이 없습니다. 어떤 식 으로든 해시를 저장하려고합니다 (md5, md5 + salt , 뭐든간에). 대신 제대로 작성된 MD5 해시가 될 가능성이 높아 지도록 32 자의 16 진수 문자열을 사용할 수 있습니다.

이 암호 예제 만이 유일한 시나리오는 아니며이 항목의 설명에 대한 좋은 설명입니다.

그래서 대답은 무엇입니까? 나는 해결책이 하나도 없다고 생각합니다. 때로는 데이터를 두 번 검증하는 것이 필요할 것입니다 (필요합니까?). 때로는 모델에서 한 번만 할 것입니다. 가능한 한 응용 프로그램의 요구 사항과 최대한 일치 시키십시오.

0

양식의 에스테틱 유효성 검사 및 모델의 비즈니스 규칙 유효성 검사는 어떨까요?

예를 들어 등록 양식을 작성하십시오.

양식은 전자 메일 필드가 잘리고 유효한 전자 메일, 암호/암호 확인 필드가 동일하며 사용자가 동의 함 확인란을 선택했음을 보증합니다.

등록 모델은 전자 메일이 테이블에서 아직 가져 오지 않았 음을 확인하고 암호를 암호화하고 해시합니다.

내가 두 사람을 보통 나눈 것입니다.

0

사용자 입력은 입력 양식과 관련되어 입력 될 때 유효해야합니다 (즉, 양식 유효성 검사를 수행하십시오. 숫자가 있어야하는 텍스트 상자가 숫자 여야 함).

비즈니스 로직은 모델에 따라 다르므로 모델에서 유효성을 검사해야합니다 (즉, 해당 룸을 이미 예약했는지 확인해야합니다).

모델 수준에서 유효성을 검사 할 때의 문제점은 모델이 다른 방식으로 사용될 수 있다는 것입니다. 한 시나리오의 올바른 입력이 다른 시나리오의 올바른 입력이 아닐 수 있습니다.

다른 문제는 일반적으로 잘못된 입력이있는 양식 컨트롤 주위에 빨간색 상자를 표시하는 것과 같이 상황에 맞는 유효성 검사가 필요하다는 것입니다.

모델이나 데이터베이스가 사용자 코드가 완전히 잘못된 작업 (제약 조건 등)을 수행하지 않도록 추가 검증을 수행 할 수 있습니다.

0

피터 베일리의 암호 예는 우수합니다. 입력 확인이 보장되는 동안 원래의 일반 텍스트 비밀번호가 보안 요구 사항 (문자 수, 문자 수 등)에 해당하는 경우에만 사용자 모델이 유효성을 검사 할 수 있습니다 (일반 텍스트로 저장되지 않기 때문에 해시로 저장 됨).). 따라서 모델 유효성 검사와 양식/입력 유효성 검사가 이상적으로 별도의 재사용 가능한 구성 요소로 필요하며 직접 비대화 된 컨트롤러 작업으로는 필요하지 않습니다.

입력 유효성 검사를 화이트리스트 유효성 검사 ("허용됨 양호")로, 모델 유효성 검사를 블랙리스트 유효성 검사 ("알려진 불량 불량")로 생각하십시오. 블랙리스트 유효성 검사는 모델 계층이 매우 특정한 사용 사례에 지나치게 제약되지 않도록 허용하는 반면 허용 목록 유효성 검사는 더욱 안전합니다.

잘못된 모델 데이터는 항상 외부 소스에서 오는 잘못된 입력 값이 예기치 않은 것이 아니라 오히려 일반적이지 않은 반면 (예외가 발생하지 않으면 응용 프로그램을 계속 실행할 수 있어야 함) 예외를 발생시킵니다 실수).

도 참조하십시오. https://lastzero.net/2015/11/form-validation-vs-model-validation/