MVC에서 모델은 유효성 검사를 처리해야합니까?

MVC 패턴을 사용하기 위해 개발 한 웹 응용 프로그램을 다시 작성하려고하는데 모델에서 유효성 검사를 처리해야하는지 잘 모르겠습니다. 예를 들어, 다음과 같이 내 모델 중 하나를 설정하고 있습니다.

class AM_Products extends AM_Object 
{
    public function save( $new_data = array() ) 
    {
        // Save code
    }
}

첫 번째 질문 : 내 저장 메소드가 $ new_data에서 유효성 검사 함수를 호출해야하는지 또는 데이터가 이미 유효성 검사를 받았다고 생각하는지 궁금합니다.

또한 유효성 검사를 제공하는 경우 데이터 형식을 정의하는 일부 모델 코드는 다음과 같습니다.

class AM_Products extends AM_Object
{
    protected function init() // Called by __construct in AM_Object
    {
        // This would match up to the database column `age`
        register_property( 'age', 'Age', array( 'type' => 'int', 'min' => 10, 'max' => 30 ) ); 
    }
}

두 번째 질문 : AM_Object의 모든 하위 클래스는 해당 특정 객체의 데이터베이스에있는 각 열에 대해 register_property를 실행합니다. 이것이 좋은 방법인지 잘 모르겠습니다.

세 번째 질문 : 모델에서 유효성 검사를 처리해야하는 경우 오류 메시지 또는 오류 코드를 반환하고 뷰에서 코드를 사용하여 적절한 메시지를 표시해야합니까?

첫 번째 답변 : 모델의 핵심 역할은 무결성을 유지하는 것입니다. 그러나 사용자 입력 처리는 컨트롤러의 책임입니다.

즉, 컨트롤러는 사용자 데이터 (대부분은 문자열 임)를 의미있는 것으로 변환해야합니다. 구문 분석이 필요합니다 (예 : 다른 소수 연산자 등이있는 경우 로캘과 같은 항목에 따라 달라질 수 있음).
따라서 "데이터가 제대로 구성되어 있습니까?"와 같이 실제 유효성 검사는 컨트롤러에서 수행해야합니다. 그러나 "데이터가 의미가 있는가?"와 같은 검증 모델 내에서 수행해야합니다.

예를 들어이를 명확하게하려면 :
응용 프로그램에서 날짜와 함께 일부 엔터티를 추가 할 수 있다고 가정합니다 ( 예 : 마감일 문제). 날짜가 단순한 Unix 타임 스탬프로 표시 될 수있는 API가있을 수 있지만 HTML 페이지에서 오는 경우 다른 값 세트 또는 MM / DD / YYYY 형식의 문자열이됩니다. 모델에서이 정보를 원하지 않습니다. 각 컨트롤러가 개별적으로 날짜를 파악하려고합니다. 그러나 날짜가 모델로 전달 될 때 모델은 무결성을 유지해야합니다. 예를 들어, 휴일 / 일요일 등의 과거 날짜 또는 날짜를 허용하지 않는 것이 좋습니다.

컨트롤러에는 입력 (처리) 규칙이 포함되어 있습니다. 모델에 비즈니스 규칙이 포함되어 있습니다. 어떤 일이 있어도 비즈니스 규칙을 항상 적용하기를 원합니다. 컨트롤러에 비즈니스 규칙이 있다고 가정하면 다른 컨트롤러를 만들어야하는 경우이를 복제해야합니다.

두 번째 답변 : 이 방법은 의미가 있지만 방법을 더욱 강력하게 만들 수 있습니다. 마지막 매개 변수는 배열 IContstraint이 아니라 다음과 같이 정의 된 인스턴스 여야합니다 .

interface IConstraint {
     function test($value);//returns bool
}

그리고 숫자의 경우 다음과 같은 것을 가질 수 있습니다.

class NumConstraint {
    var $grain;
    var $min;
    var $max;
    function __construct($grain = 1, $min = NULL, $max = NULL) {
         if ($min === NULL) $min = INT_MIN;
         if ($max === NULL) $max = INT_MAX;
         $this->min = $min;
         $this->max = $max;
         $this->grain = $grain;
    }
    function test($value) {
         return ($value % $this->grain == 0 && $value >= $min && $value <= $max);
    }
}

또한 나는 'Age'정직하게 표현 해야 할 것이 무엇인지 알지 못한다 . 실제 속성 이름입니까? 기본적으로 규칙이 있다고 가정하면 매개 변수는 함수의 끝으로 이동하여 선택 사항이 될 수 있습니다. 설정하지 않으면 DB 열 이름 의 to_camel_case 가 기본값이됩니다 .

따라서 예제 호출은 다음과 같습니다.

register_property('age', new NumConstraint(1, 10, 30));

인터페이스 사용의 요점은 갈수록 점점 더 많은 제약 조건을 추가 할 수 있으며 원하는만큼 복잡 할 수 있다는 것입니다. 문자열이 정규식과 일치합니다. 날짜가 7 일 이상이어야합니다. 등등.

세 번째 답변 : 모든 모델 엔터티에는 다음과 같은 방법이 있어야합니다 Result checkValue(string property, mixed value). 데이터 를 설정 하기 전에 컨트롤러가 호출해야 합니다. 는 Result검사가 실패했는지에 대한 모든 정보를 가지고 있고, 컨트롤러가 따라보기로 사람들을 전파 할 수 있도록했던 경우, 이유를 제시해야한다.
모델에 잘못된 값이 전달되면 모델은 예외를 발생시켜 응답해야합니다.

"back2dos"에 전적으로 동의하지 않습니다. 권장 사항은 항상 별도의 양식 / 유효성 검사 계층을 사용하여 컨트롤러가 입력 데이터를 모델로 보내기 전에 유효성 검사에 사용할 수 있도록하는 것입니다.

이론적 관점에서 볼 때 모델 유효성 검사는 신뢰할 수있는 데이터 (내부 시스템 상태)에서 작동하며 언제라도 이상적으로 반복 할 수 있어야하며, 입력 유효성 검사는 신뢰할 수없는 출처에서 온 데이터 (사용 사례 및 사용자 권한에 따라)에서 한 번만 명시 적으로 작동해야합니다.

이러한 분리를 통해 의존성 주입을 통해 느슨하게 결합 할 수있는 재사용 가능한 모델, 컨트롤러 및 양식을 작성할 수 있습니다. 입력 검증은 화이트리스트 검증 ( "알려진 것으로 인정")으로, 모델 검증은 블랙리스트 검증 ( "알려진 것으로 거부")으로 생각하십시오. 화이트리스트 유효성 검사는보다 안전하지만 블랙리스트 유효성 검사는 모델 계층이 특정 사용 사례로 지나치게 제한되는 것을 방지합니다.

유효하지 않은 모델 데이터는 항상 예외를 발생시켜야하며 (그렇지 않으면 응용 프로그램은 실수를 알리지 않고 계속 실행할 수 있습니다) 외부 소스에서 오는 유효하지 않은 입력 값은 예상치 못한 것이 아니라 일반적입니다 (실패하지 않은 사용자가없는 경우).

참조 : https://lastzero.net/2015/11/why-im-using-a-separate-layer-for-input-data-validation/

예, 모델은 유효성 검사를 수행해야합니다. UI도 입력의 유효성을 검사해야합니다.

유효한 값과 상태를 결정하는 것은 모델의 책임입니다. 때때로 그러한 규칙은 자주 바뀝니다. 이 경우 메타 데이터에서 모델을 피드하거나 장식합니다.

좋은 질문입니다!

월드 와이드 웹 개발과 관련하여 다음을 요청하면 어떻게 될까요?

"사용자 인터페이스에서 잘못된 사용자 입력이 컨트롤러에 제공되는 경우 컨트롤러 는 일종의 주기적 루프로 View를 업데이트하여 명령 및 입력 데이터를 처리하기 전에 정확하게해야 합니까? 어떻게? 뷰는 정상 상태에서 어떻게 업데이트됩니까? 뷰는 모델과 밀접하게 연결되어 있습니까? 사용자 입력 유효성 검사 는 모델의 핵심 비즈니스 논리 입니까 , 아니면 모델에 대한 예비 작업 입니까? 따라서 컨트롤러 내부에서 발생해야합니다 (사용자 입력 데이터가 요청의 일부이기 때문에)?

(실제로 좋은 입력을 얻을 때까지 모델을 인스턴스화하는 데 지연이 발생할 수 있습니까?)

내 의견은 모델이 모델 인스턴스화 이전 (그리고 모델이 입력 데이터를 가져 오기 전에) 발생 해야하는 기본 HTTP 요청 입력 유효성 검사에 의해 방해받지 않고 순수하고 깨끗한 환경을 가능한 한 많이 관리해야한다는 의견입니다 . 상태 데이터 (영구적 또는 다른 방식) 및 API 관계 관리가 모델의 세계이므로 컨트롤러에서 기본 HTTP 요청 입력 유효성 검사가 발생하도록합니다.

요약.

1) 컨트롤러와 메소드가 존재해야 다른 경로를 진행할 수 있으므로 경로를 URL에서 구문 분석하십시오. 이는 진정한 컨트롤러에 도달하기 전에 프론트 컨트롤러 영역 (라우터 클래스)에서 반드시 발생해야합니다. 어. :-)

2) 모델에는 HTTP 요청, 데이터베이스, 파일, API 및 네트워크와 같은 많은 입력 데이터 소스가있을 수 있습니다. 모든 입력 유효성 검증을 모델 에 배치하려는 경우 프로그램에 대한 비즈니스 요구 사항의 일부인 HTTP 요청 입력 유효성 검증 을 고려 하십시오. 경우 폐쇄.

3) 그러나 HTTP 요청 입력 이 좋지 않은 경우 많은 객체를 인스턴스화하는 비용을 겪는 것은 근시안적입니다 ! 모델과 모든 복잡성 (예, API 및 DB 입력 / 출력 데이터에 대한 더 많은 유효성 검사기)을 인스턴스화하기 전에 유효성을 검사 하여 ** HTTP 요청 입력 **이 좋은지 ( 요청과 함께 제공됨) 알 수 있습니다.

다음을 테스트하십시오.

a) HTTP 요청 방법 (GET, POST, PUT, PATCH, DELETE ...)

b) 최소 HTML 컨트롤 (충분한 것이 있습니까?)

c) 최대 HTML 컨트롤 (너무 많습니까?).

d) 올바른 HTML 컨트롤 (올바른 컨트롤이 있습니까?)

e) 입력 인코딩 (일반적으로 인코딩 UTF-8입니까?)

f) 최대 입력 크기 (입력이 범위를 벗어 났습니까?).

문자열과 파일을 얻을 수 있으므로 요청이 서버에 부딪히면 모델이 인스턴스화 될 때까지 기다리는 것이 매우 비쌀 수 있습니다.

여기에 설명 한 것은 컨트롤러를 통해 들어오는 요청 의 의도 에 부딪칩니다 . 의도 확인을 생략하면 응용 프로그램이 더 취약 해집니다. 의도 는 좋 거나 ( 기본 규칙에 따라 재생) 나쁘게 (기본 규칙 외부로 나가기) 수 있습니다.

HTTP 요청의 의도 는 전적으로 또는 전혀없는 제안입니다. 모든 것이 통과되거나 요청이 유효하지 않습니다 . 모델에 아무것도 보낼 필요가 없습니다.

이 기본 HTTP 요청 의도 수준은 일반 사용자 입력 오류 및 유효성 검사와 관련 이 없습니다 . 내 응용 프로그램에서 HTTP 요청은 위의 다섯 가지 방법으로 유효해야합니다. A의 심층 경우 말하기의 방법, 당신은 서버 측에서 사용자 입력 유효성 검사에 결코 어떤 이 다섯 가지가 실패합니다.

그렇습니다. 파일 입력조차도 프런트 엔드의 시도와 일치해야 사용자에게 허용되는 최대 파일 크기를 확인하고 알려줍니다. HTML 만? JavaScript가 없습니까? 그러나 사용자는 너무 큰 파일을 업로드 한 결과 (주로 모든 양식 데이터가 손실되고 시스템에서 쫓겨날 수 있음)에 대해 알려야합니다.

4) 이것은 HTTP 요청 입력 데이터 가 애플리케이션의 비즈니스 로직의 일부가 아님을 의미합니까 ? 아니요, 컴퓨터가 유한 한 장치이므로 리소스를 현명하게 사용해야한다는 의미입니다. 나중에 악의적 인 활동을 더 빨리 중지하는 것이 좋습니다. 나중에 중지하기 위해 더 많은 컴퓨팅 리소스를 지불해야합니다.

5) HTTP 요청 입력 이 잘못된 경우 전체 요청이 잘못되었습니다 . 그것이 내가 보는 방법입니다. 올바른 HTTP 요청 입력의 정의는 모델의 비즈니스 요구 사항에서 파생되지만 자원 구분 지점이 있어야합니다. 잘못된 요청을 종료하고 "오, 이봐, 신경 쓰지 마. 나쁜 요청."

사용자가 합리적인 입력 실수를 저지른 것이 아니라 HTTP 요청이 범위를 벗어난 것으로 판단하여 악의적 인 것으로 선언하고 즉시 중지해야합니다.

6) 따라서 돈 때문에 HTTP 요청 (METHOD, URL / route 및 데이터)이 모두 좋거나 다른 방법으로 진행할 수 있습니다. 강력한 모델에는 이미 검증 작업이 필요하지만, 좋은 자원 목자는 "나의 길 또는 높은 길입니다. 올바르거나 오지 마십시오"라고 말합니다.

그러나 그것은 당신의 프로그램입니다. "한 가지 이상의 방법이 있습니다." 어떤 방법은 다른 방법보다 시간과 비용이 많이 듭니다. 나중에 (모델에서) HTTP 요청 데이터의 유효성을 검사하면 응용 프로그램 수명 기간 동안 (특히 확장 또는 축소되는 경우) 비용이 더 많이 듭니다.

유효성 검사기가 모듈 식인 경우 컨트롤러에서 기본 * HTTP 요청 입력 ** 유효성을 검사해도 문제가되지 않습니다. 전략화 된 Validator 클래스 만 사용하십시오. 유효성 검사기는 때로는 특수 유효성 검사기 (이메일, 전화, 양식 토큰, 보안 문자 등)로 구성되기도합니다.

어떤 사람들은 이것이 완전히 잘못된 것으로보고 있지만, Gang of Four가 Design Patterns : Reusable Object-Oriented Software의 요소를 작성할 때 초기 단계에있었습니다 .

===================================================== =========================

이제는 정상적인 사용자 입력 유효성 검사 (HTTP 요청이 유효한 것으로 간주 된 후)와 관련되어 있으므로 사용자가 생각해야 할 내용이 엉망이되면보기를 업데이트하고 있습니다! 이러한 종류의 사용자 입력 유효성 검사는 모델에서 발생해야합니다.

프론트 엔드에서 JavaScript를 보증하지 않습니다. 즉, 오류 상태로 응용 프로그램 UI를 비동기식으로 업데이트 할 수있는 방법이 없습니다. 진정한 점진적 향상은 동기 사용 사례에도 적용됩니다.

동기 사용 사례에 대한 회계는 일부 사람들이 모든 UI 트릭 (상태 표시 / 숨기기 제어, 사용 안함 / 사용 제어)의 상태를 추적하는 데 시간이 걸리고 번거롭기 때문에 점점 더 많이 잃어 버리는 기술입니다. , 오류 표시, 오류 메시지) (일반적으로 배열 상태 추적)

업데이트 : 다이어그램에서을 View참조해야 한다고 말합니다 Model. 아니요 . 느슨한 결합을 유지 View하려면 데이터를 보낸 사람에게 전달해야합니다 Model.