Yi Wei의 진술에 동의해야 합니다. V는 사용자 경험을 보장하기 위해 검증되었으므로 사용자는 제출 후 다시 돌아가 오류를 수정합니다. 데이터 자체에 대한 검증(데이터가 사용자의 것인지, 데이터 상태 변경이 논리적 요구 사항을 충족하는지 여부), M은 데이터의 존재를 확인하기 위해 거래하며, 데이터가 존재하지 않으면 아래로 갈 필요가 없습니다. , 비정상임에 틀림없습니다.
일반적으로 MVC 프레임워크에서는 비즈니스 처리를 기반으로 서비스 레이어가 추가됩니다. 모델은 직접 ORM 매핑되거나 폐기되며 DAO를 작성합니다. 이제 검증이 수행되는 레이어에 대해 이야기하겠습니다. 방법은 컨트롤러 레이어 C와 서비스 레이어 S가 모두 이루어져야 하는데, 웹사이트가 발전할수록 원격통화를 위한 공용 서비스 컴포넌트로 서비스를 분리해야 하므로 컨트롤러 레이어에서 검증을 하지 않는다면 말이죠. 데이터 요청의 경우 공공 서비스에 직접 전송합니다. 데이터에 문제가 있는 경우 오류가 반환되면 이는 분명히 네트워크 IO를 낭비하게 됩니다. 따라서 컨트롤러 수준에서 데이터 확인을 수행했다면 , 데이터가 잘못된 경우 직접 예외를 발생시킵니다. RPC를 통해 원격 호출을 할 필요가 없습니다
일반적으로 MVC의 C-M 사이에 서비스 레이어를 추가합니다(그러나 C 또는 M의 일부로 이해될 수도 있음). 이 레이어는 뷰와 컨트롤러에서 분리되도록 설계되었으며 외부로 독립적으로 제거될 수 있습니다( API).
그래서,
뷰에서는 단일 값에 대해 상대적으로 약한 적법성 검사를 수행합니다.
컨트롤러에서 외부 요청 패킷의 적법성을 확인하고 일부 사용자 인터페이스 권한을 확인하세요.
서비스에서 엄격한 데이터 합법성 검증, 비즈니스 로직 제약 검증 및 사용자 데이터 권한 검증을 수행합니다.
모델 내 데이터의 물리적 합법성 검증을 수행합니다.
피험자가 Python의 Django 또는 Flask와 같은 프레임워크를 사용한 경우 Form 클래스도 있음을 알 수 있습니다. 일반적으로 사용자 콘텐츠 확인 논리는 Form 클래스에 배치됩니다. 때로는 상황에 따라 동일한 데이터 모델에 대해 서로 다른 유효성 검사 규칙을 만들어야 할 수도 있기 때문입니다. 물론 Django는 모델 레이어 검증도 지원합니다. 상대적으로 말하면. 양식 레이어는 낮은 수준의 결합으로 이를 수행합니다.
Yi Wei의 진술에 동의해야 합니다. V는 사용자 경험을 보장하기 위해 검증되었으므로 사용자는 제출 후 다시 돌아가 오류를 수정합니다. 데이터 자체에 대한 검증(데이터가 사용자의 것인지, 데이터 상태 변경이 논리적 요구 사항을 충족하는지 여부), M은 데이터의 존재를 확인하기 위해 거래하며, 데이터가 존재하지 않으면 아래로 갈 필요가 없습니다. , 비정상임에 틀림없습니다.
이 질문은 특정 애플리케이션, 특정 언어, 특정 프레임워크와 결합하여 분석해야 하며, 심지어 팀원의 스타일 및 구성과도 관련이 있습니다.
저는 개인적으로 M이 검증 로직을 수행하고 예외를 던진 다음 C를 캡처하여 출력을 위해 프런트 엔드에서 요구하는 형식으로 변환하는 것을 선호합니다. 이 초기 코드는 다소 장황할 수 있지만 논리적 무결성 및 이후 확장에 더 유리합니다.
또 다른 접근 방식은 M과 C 사이에 소위 논리 계층을 구축하여 검증 논리와 비즈니스 논리의 일부를 처리하는 것입니다
일반적으로 MVC 프레임워크에서는 비즈니스 처리를 기반으로 서비스 레이어가 추가됩니다. 모델은 직접 ORM 매핑되거나 폐기되며 DAO를 작성합니다. 이제 검증이 수행되는 레이어에 대해 이야기하겠습니다. 방법은 컨트롤러 레이어 C와 서비스 레이어 S가 모두 이루어져야 하는데, 웹사이트가 발전할수록 원격통화를 위한 공용 서비스 컴포넌트로 서비스를 분리해야 하므로 컨트롤러 레이어에서 검증을 하지 않는다면 말이죠. 데이터 요청의 경우 공공 서비스에 직접 전송합니다. 데이터에 문제가 있는 경우 오류가 반환되면 이는 분명히 네트워크 IO를 낭비하게 됩니다. 따라서 컨트롤러 수준에서 데이터 확인을 수행했다면 , 데이터가 잘못된 경우 직접 예외를 발생시킵니다. RPC를 통해 원격 호출을 할 필요가 없습니다
상황에 따라 다릅니다.
뚱뚱한 모델, 마른 컨트롤러.
Echang 코딩에는 원칙이 있습니다. 인터페이스는 서로를 신뢰하지 않습니다.
프레임워크 없이 직접 작성한다면 C 레이어에 속해야 합니다. 그러나 더 많은 프레임워크가 m 레이어에 배치되는 경향이 있습니다.
또한 v 레이어에서만 입력 확인을 수행하지 마세요. 프런트엔드 항목은 쉽게 우회할 수 있으므로 보안 위험이 발생할 수 있습니다.
각 레이어는 서로 다른 강조점을 가지고 이루어져야 합니다.
일반적으로 MVC의 C-M 사이에 서비스 레이어를 추가합니다(그러나 C 또는 M의 일부로 이해될 수도 있음). 이 레이어는 뷰와 컨트롤러에서 분리되도록 설계되었으며 외부로 독립적으로 제거될 수 있습니다( API).
그래서,
뷰에서는 단일 값에 대해 상대적으로 약한 적법성 검사를 수행합니다.
컨트롤러에서 외부 요청 패킷의 적법성을 확인하고 일부 사용자 인터페이스 권한을 확인하세요. 서비스에서 엄격한 데이터 합법성 검증, 비즈니스 로직 제약 검증 및 사용자 데이터 권한 검증을 수행합니다. 모델 내 데이터의 물리적 합법성 검증을 수행합니다.
피험자가 Python의 Django 또는 Flask와 같은 프레임워크를 사용한 경우 Form 클래스도 있음을 알 수 있습니다. 일반적으로 사용자 콘텐츠 확인 논리는 Form 클래스에 배치됩니다. 때로는 상황에 따라 동일한 데이터 모델에 대해 서로 다른 유효성 검사 규칙을 만들어야 할 수도 있기 때문입니다. 물론 Django는 모델 레이어 검증도 지원합니다. 상대적으로 말하면. 양식 레이어는 낮은 수준의 결합으로 이를 수행합니다.
Simple MVC는 일반적으로 모델 계층에서 FORM 검증을 수행하지만 보다 성숙한 솔루션은 일반적으로 FORM을 분리합니다. 예를 들어 Joomla는 FORM 계층을 가지며 구조적으로 모델 계층에 속합니다. 기능 구현은 모델 레이어와 아무 관련이 없는 것 같습니다.
사실 적법성 확인도 로컬측과 서버측으로 나누어져 있습니다.
예를 들어, 입력이 비어 있으면 V 계층에서 확인하고, 입력 형식이 올바르지 않으면 M 계층에서 확인합니다.
적격 여부를 더 확인하고 싶다면 M 레이어에 올려놓고 서버에 접속해 확인할 수 있다.