한 곳에서 클라이언트 측 및 서버 측 유효성 검사 관리

나는 하나가있는 경우 보드에 100 % 야 한다 확실히 클라이언트 측 및 서버 측 데이터 유효성 검사를 모두 사용합니다.

그러나 내가 작업 한 프레임 워크와 환경에서 내가 본 접근 방식은 결코 건조하지 않았습니다. 대부분의 경우 계획이나 패턴이 없습니다. 유효성 검사는 모델 사양에 작성되고 유효성 검사는 뷰의 형식으로 작성됩니다. (참고 : 대부분의 직접 경험은 Rails, Sinatra 및 PHP w / jQuery 사용)

이를 종합 해보면 일련의 유효성 검사 (예 : 모델 이름, 필드, 조건)가 필요한 클라이언트 측 및 서버 측 자료를 모두 생성 할 수있는 생성기를 만드는 것이 어렵지 않은 것 같습니다. 또는 이러한 도구는 서버 측 유효성 검사 (예 : validatesActiveRecord 모델 의 코드)를 수행하고 클라이언트 쪽 유효성 검사 (예 : jQuery 플러그인)를 생성하여 양식에 적용 할 수 있습니다.

분명히 위의 내용은 단지 "이 아이디어를 가졌다"고 공식적인 제안이 아닙니다. 이런 종류의 일은 아이디어가 저를 때릴 때보 다 분명히 어렵습니다.

그러면 데이터 유효성 검사를위한 "한 번 쓰기, 서버 및 클라이언트에서 실행"기술을 설계하는 방법에 어떻게 접근 할 것입니까?

관련 하위 주제 : 특정 프레임 워크 또는 클라이언트-서버 기술에 이와 유사한 도구가 있습니까? 하나의 검증 세트 만 유지하려고 할 때의 주요 문제점 또는 문제점은 무엇입니까?

제한된 경험에서 검증이 필요한 시점은

1. HTML을 사용한 프리젠 테이션 레벨
2. 발표 후 레벨 (예 : Javascript 유효성 검사)에서
3. 여러 필드 간의 상호 작용을 함께 확인해야하는 조합 수준에서
4. 비즈니스 로직 수준에서
5. 데이터베이스 수준에서.

각각의 언어, 타이밍 및 트리거가 다릅니다. 예를 들어, 한 부분 만 유효성 검사 하지 않는 한 전체 레코드가 일관된 상태가되기 전에 필드의 유효성을 검사하는 것은 의미가 없습니다 . 데이터베이스 레벨의 제한 조건은 커미트 이전의 끝에 만 적용 가능해야하며 조각 단위로 쉽게 수행 할 수 없습니다.

관련 개념은 데이터를 나타내는 것이 각 레벨마다 다릅니다. 간단한 예는 웹 브라우저가 CP1290과 같은 텍스트를 나타내는 반면 데이터베이스는 UTF-8로이를 나타내는 것입니다. 두 문자열의 길이가 다르므로 길이 제한을 적용하는 것이 어색합니다.

종종 솔루션을 제한하는 한 가지 고려 사항은 네트워크 왕복입니다. 클라이언트는 네트워크를 통해 메시지를 보내지 않고 사용자 데이터의 유효성을 검사해야합니다. 다시 말해, 사용자가 제출 버튼을 누르면 클라이언트는 데이터를 로컬에서 검증해야합니다.

먼저이 제한이 없다고 가정 해 봅시다. 우리는 검증 문제를 명확하게 설명하는 네트워크 엔드 포인트와 통신 할 수 있습니다. 예를 들어, 바닐라 HTTP 오류 코드로 응답하지 않고 새 사용자 레코드를 제출하면 문제를 항목별로 자세히 설명하는 JSON 응답을 반환 할 수 있으며 클라이언트는 발생한 문제를 반영하여 디스플레이를 스마트하게 업데이트합니다. 엔드 포인트는 유효성 검사 게이트웨이의 역할을합니다.

건조하지만 단점이 없습니다. 첫째, 클라이언트 측에서 처리 할 수있는 유효성 검사로 서버에 부담을주는 네트워크 왕복에 달려 있습니다. 둘째, 설계는 모든 CRUD 작업이 엔드 포인트를 통해 발생할 것으로 예상하지만 개발자와 프로세스 가 데이터베이스에 직접 접근하여 데이터 액세스 계층을 우회하는 경우는 어떻습니까?

이러한 단점을 극복하기 위해 우리의 솔루션을 다시 살펴 보자. 대신 유효성 검사를 메타 데이터로 저장하고 전달하십시오.

{field: 'username', type: 'required'}
{field: 'username', type: 'unique'} //requires a network roundtrip
{field: 'password', type: 'length', min: 10, max: 50}
{field: 'password', type: 'contains', characters: ['upper', 'special', 'letter', 'number']}

클라이언트와 서버 모두이 데이터를 해석하고 적용하기위한 메커니즘 (예 : 엔진)이 있습니다. (일부에서는 해석 부분과 선언 부분을 분리하므로 이것을 자유 모나드라고 부릅니다.) JavaScript에서는 각 정보를 작업 함수에 매핑 할 수 있습니다. 부팅하기 위해 데이터베이스를 포함한 모든 아키텍처 계층에 대해 일관된 유효성 검사를 시행 할 수 있습니다.

한 가지 방법은 서버와 클라이언트 측에서 동일한 언어 / 프레임 워크를 사용하는 것입니다.

예 :

Node.js :: JavaScript의 클라이언트 / 서버 GET :: Java의 클라이언트 / 서버

이 경우, 대부분의 "도메인 객체"코드는 공통적이며 여기에는 유효성 검사가 포함됩니다. 프레임 워크는 필요에 따라 코드를 호출합니다. 예를 들어, "제출"전에 서버 측 웹 서비스에서 동일한 코드가 호출됩니다.

편집 (2014 년 6 월) : Java 8을 사용하면 Java 응용 프로그램에서도 JS 유효성 검사 코드를 쉽게 통합 할 수 있습니다. Java 8에는보다 영구적 인 새로운 JS 실행 엔진이 있습니다 (예 : invokeDynamic을 사용함).

나는 단지 같은 문제에 대해 생각하고있었습니다. C #과 javascript 모두에서 추상 구문 트리를 얻기 위해 ANTLR을 사용하려고 생각했습니다. 거기에서 트리 워커를 사용하여 언어로 지정된 조치를 유효성 검증 할 오브젝트에 적용하십시오.

따라서 필요한 경우 데이터베이스에 필요한 유효성 검사에 대한 설명을 저장할 수 있습니다.

이것이 내가 문제에 접근하는 방법입니다.