뷰가 유효성 검사를 수행하지 않아야합니까?

" MVC에서 모델이 유효성 검사를 처리해야합니까? "를 읽었습니다 . 유효성 검사 논리가 MVC 웹 사이트에서 어디로 가야하는지 궁금하기 때문입니다. 맨 위 답변의 한 줄은 다음과 같습니다. "컨트롤러는 유효성 검사를 처리하고 모델은 검증을 처리해야합니다."

나는 그것을 좋아했지만 몇 가지 이유로 View에서 데이터 유효성 검사를 수행하지 않는 이유가 궁금합니다.

1. 뷰는 일반적으로 강력한 유효성 검사 지원 (JS 라이브러리, HTML5 태그)
2. 뷰는 로컬로 유효성을 검사하여 네트워크 IO를 줄입니다.
3. UI는 이미 데이터 유형 (날짜에 대한 캘린더, 숫자에 대한 스피너)을 염두에두고 설계되었으므로 유효성 검사에서 하나의 작은 단계입니다.

여러 장소에서 검증하는 것은 MVC의 책임 분리 개념과 상반되므로 "두 가지 모두에서 수행"하는 것은 부적절 해 보입니다. 컨트롤러에서만 데이터 유효성 검사를 수행하고 있습니까?

모든 유효성 검사를 수행해야한다고 말할 수있는 단일 장소가 있다고 생각하지 않습니다. 이는 표준 asp.net mvc 웹 사이트에서 함께 작동하는 몇 가지 다른 경쟁 프로그래밍 전략이 있기 때문입니다.

먼저 도메인 로직을 모델로, '액션'로직을 컨트롤러로, 디스플레이를 뷰로 분리하는 아이디어가 있습니다. 이것은 브라우저가 단순히 뷰의 렌더링을 제공하여 서버에서 모든 논리가 발생한다는 아이디어를 기반으로합니다.

그런 다음 클라이언트 측 자바 스크립트를 사용하여 View를 확장합니다. 요즘 Jquery / knockout / angular를 사용하는 '한 페이지 웹 사이트'아이디어가 일반적인 관행이 될 정도로 발전했습니다.

이 방법은 자체적으로 MVC 또는 MVVM 패턴을 구현하는 전체 클라이언트 측 응용 프로그램을 작성하는 것과 같습니다. 뷰를 데이터 전송 객체로, 컨트롤러를 서비스 엔드 포인트로 거부합니다. 모든 비즈니스 및 UI 로직을 클라이언트로 이동

이는 더 나은 사용자 경험을 제공 할 수 있지만 본질적으로 신뢰할 수없는 클라이언트를 신뢰해야합니다. 따라서 클라이언트가 요청을 얼마나 잘 사전 검증하는지에 관계없이 서버에서 유효성 검증 로직을 수행해야합니다.

또한 종종 고객이 수행 할 수없는 검증 요구 사항이 있습니다. 예. '새 ID가 고유합니까?'

최상의 경험 / 성능을 제공하기 위해 만든 모든 응용 프로그램은 반드시 여러 프로그래밍 패러다임을 빌려서 목표를 달성하기 위해 타협해야합니다.

여러 장소에서 검증하는 것은 MVC의 책임 분리 개념과 상반되므로 "두 가지 모두에서 수행"하는 것은 부적절 해 보입니다.

여기서 고려해야 할 여러 가지 검증 책임이있을 수 있습니까? 당신이 # 3에서 말했듯이 :

UI는 이미 데이터 유형 (날짜에 대한 캘린더, 숫자에 대한 스피너)을 염두에두고 설계되었으므로 유효성 검사에서 하나의 작은 단계입니다.

아마도 다음과 같습니다.

보기 : 입력 유형, 형식, 요구 사항 확인 ... 비즈니스 로직과 관련이없는 기본 사용자 입력 확인. 서버를 요청하여 네트워크 트래픽을 생성하기 전에이 솜털 같은 것들을 모두 잡아라.

모델 : 데이터의 비즈니스 문제를 확인합니다. 비즈니스 규칙에 따라 합법적 인 가치입니까? 그렇습니다. 숫자 값이지만 (보기에서 확인 했음) 의미가 있습니까?

그냥 생각이야

지속성에 대한 유효성 검사가 필요하다고 가정합니다.

View뿐만 아니라 Model도 유효성 검사를 처리하지 않아야합니다. IT 시절에 DDD 가 실제로 일을 올바르게 수행 할 수있는 방법 중 하나 라는 것을 깨달았습니다 . 수업은 실제로 그들이해야 할 일에 대한 책임이 있습니다.

도메인 기반 설계를 따르는 경우 모델에 비즈니스 논리가 포함됩니다. 그러나 검증을 포함하지 않는 이유는 무엇입니까?

도메인 계층을 유지 하는 Data Mapper대신 이미 사용하고 있다고 가정 해 봅시다 Active Record. 그러나 여전히 모델의 유효성을 검사하기를 원하므로 모델에 유효성 검사를 추가하십시오.

interface Validation
{
    public function validate();
}

class ConcreteModel extends MyModel implements Validation
{
    public function validate() { // the validation logic goes here }
}

유효성 검사 논리를 사용하면 모델을 MySQL 데이터베이스에 올바르게 삽입 할 수 있습니다. 몇 개월이 지나면 MySQL과는 다른 유효성 검사 규칙이 필요한 noSQL 데이터베이스뿐만 아니라 데이터베이스에도 모델을 저장하려고합니다.

그러나 문제가 있습니다. 검증 방법은 하나 뿐이지 만 Model두 가지 방법으로 검증해야합니다 .

모델 은 담당 업무를 수행 하고 비즈니스 로직을 관리하고 잘 수행해야합니다. 유효성 검사는 비즈니스 논리가 아닌 지속성에 연결되므로 유효성 검사는 모델에 속하지 않습니다 .

당신은 작성해야합니다 Validator, 매개 변수로 자신의 생성자에서 유효성을 검사하는 모델을 걸릴 구현되는 대신들 Validation인터페이스를 이러한 사용 Validator하여 객체의 유효성을 검사들.

interface Validation
{
    public function validate();
}

class MySQLConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model here
    }
}

class RedisConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model with different set of rules here
    }
}

나중에 언제라도 다른 지속성 계층에 대해 다른 유효성 검사 방법을 추가하기로 결정한 경우 (Reds와 MySQL이 더 이상 갈 길이 없다고 판단했기 때문에) 다른 인스턴스를 만들고 컨테이너를 Validator사용하여 IoC올바른 인스턴스 기반을 얻습니다. 당신의 config.

많은 개발자들에게는 Stupid Ugly Controllers에 대한 Fat 모델 이 선호되는 방법입니다.

본문의 기본 개념은

... 모델은 데이터베이스가 아니라는 점을 항상 기억하십시오. 웹 서비스에서 얻은 데이터조차도 모델로 표현할 수 있습니다! 예, 아톰 피드도! 모델에 대한 소개를 방해하는 프레임 워크는 오해를 악화시키는 이러한 선입견을 거의 설명하지 않습니다.

과

뷰는 사용자가 모델과 의도를 전달할 수 있도록 UI 생성 및 표시에만 관심이 있어야합니다 . 컨트롤러는 UI 입력을 모델의 동작으로 변환하고 모델이 제시 한 모델을 인식 한 모든 뷰의 출력을 다시 전달하는 오케 스트레이터입니다. 컨트롤러는 사용자 입력을 모델의 호출에 매핑한다는 점에서만 애플리케이션 동작을 정의해야하지만, 그 역할을 넘어 서면 다른 모든 애플리케이션 로직이 모델 내에 포함되어 있어야합니다. 컨트롤러는 무대를 설정하고 체계적인 방식으로 작업하게하는 최소한의 코드를 가진 낮은 피조물입니다.

뷰는 UI 생성 및 표시에만 관심이 있어야 사용자가 모델과 의도를 전달할 수 있는 것이 중요합니다. 모델은 저장된 데이터를 정의해야하므로 데이터의 유효성을 검사해야합니다.

개인을 기록 할 때 각 개인은 국가에서 부여한 고유 ID 번호를 가져야합니다. 이 검사는 일반적으로 UNIQUE데이터베이스 의 키 검사에 의해 수행됩니다. 주어진 각 ID 번호는 일부 제어 단계를 충족해야합니다 (홀수 자릿수의 합은 짝수 자릿수의 합과 같아야합니다). 이러한 유형의 제어는Model

컨트롤러가 사용자 데이터를 수집하여 Model전달 View하거나 반대로 사용자 데이터를 수집하여 View전달합니다 Model. 데이터 액세스 및 유효성 검사에 대한 모든 제한은에 의해 수행되어서는 안됩니다 Controller. Controller쿠키 데이터를 수집 하는 사람은 Model유효한 세션인지 또는 사용자가 응용 프로그램의이 부분에 액세스 할 수 있는지 확인하는 사람입니다.

View사용자로부터 데이터를 수집하거나 사용자에게 데이터를 제공하는 사용자 인터페이스입니다. View사용자 입력 전자 메일 주소 와 같은 방식으로 간단한 확인을 수행 할 수 있습니다 (따라서 View에서도 수행 할 수 있음). IMO.

보기는 클라이언트 측이므로 사용자 입력을 스러스트해서는 안됩니다. 자바 스크립트가 클라이언트 쪽에서 실행되지 않을 수 있습니다. 사용자는 필기 스크립트를 사용하여 스크립트를 변경하거나 브라우저를 사용하여 스크립트를 비활성화 할 수 있습니다. 클라이언트 측 유효성 검사 스크립트를 설정할 수 있지만 절대로 밀어 넣지 말고 레이어를 실제로 확인 해서는 안됩니다 Model.

뷰는 ff 목적으로 유효성 검사를 수행해야합니다.

1. ) 프런트 엔드 유효성 검사는 서버의 데이터 트래픽을 줄일 수 있습니다.
2. ) 서버에서 이동하기 전에 유효하지 않은 데이터를 처리합니다.
3. ) 더 높은 보안을 원할 경우 프런트 엔드 및 백 엔드 유효성 검사의 조합이 더 좋습니다.