나는 WCF (Windows Communication Foundation)를 사용하여 웹 서비스를 만들고 있는데, 현재 어떤 방법으로 유효성 검사를 수행하는 것이 가장 좋은지 알지 못합니다.리스트 <Customer> 모두 또는 아무것도 없음
두 가지 방법이 있습니다 : CreateCustomer(Customer) 및 CreateCustomers(List<Customer>)입니다.
고객이 고객 목록을 전달하고 일부 고객이 유효하지 않은 경우 전체 요청을 거부해야합니까? 또는 유효성 검사를 통과 한 제품을 반환하고 유효하지 않은 제품에 라벨을 붙여야합니까?
또는 CreateCustomer(Customer) 메서드를 호출하고 둘 이상의 고객을 만들려는 경우에만 반복 호출하도록 허용해야합니까?
이런 상황에서 나는 트랜잭션과 같은 접근 방식을 권장합니다.
기본적으로 식별자 나 실제 개체를 사용하여 전달하지 않은 고객이 통과하지 않았거나 예외가 발생했거나 다른 유효성 검사 실패 이벤트가 발생하는 경우 유효성을 검사합니다. 이렇게하면 파이프 라인의 다른쪽에있는 사람이 문제를 식별 할 수 있습니다.
데이터베이스에 저장하려면 트랜잭션에서이 작업을 수행하고 1-7 고객을 부분적으로 저장하는 것이 좋지만 8 번째 문제는 문제를 일으킬 수 있습니다.
각 통화에서 가능한 한 많은 작업을 수행하면 목록을 허용하고 문제가있는 경우에만 오류를 반환합니다 (나머지는 처리하는 중). 예외는 물론 원 자성 (모든 것이 든 없든)이 필요하지만 여기서는 그렇지 않은 것 같은 응용 프로그램 의미론의 관점에서 예외적 일 것입니다.
웹 서비스를 개발 중이라면 왕복 횟수를 줄이고 싶을 것입니다. 그 CreateCustomers (목록) 없애 버리는 것이 나쁜 생각입니다.
이제 거친 부분. 클라이언트에게 오류 처리 방법을 맡기는 것이 좋습니다. CreateCustomers 메서드의 시그니처를 변경하여 모두 또는 모두를 원하는지 여부를 bool에 포함 할 수 있습니다. 이 같은 것 : CreateCustomers (list, allOrNothing). 이 조작에 대한 리턴 유형은 고객에 대한 특성이있는 오브젝트의 목록이어야하고 성공했는지 여부에 관한 bool이어야합니다.
감사합니다. Jeremy. 나는 allOrNothing 플래그 접근법을 살펴볼 것입니다. 최고입니다. 스티븐. – stevenrosscampbell
웹 서비스 계약을 준수하는 데이터를 제공하는 것은 공급자의 몫입니다. 그렇지 않다면, 당신은 그들에게 적어도 나쁘지 않은 데이터를 알려주고있다. (적어도 내가 최근에 개발 한 모든 API와 비교할 때). 유효 고객과 심지어이 상황에서로 많은 문제를 혼동 할 수 있지 않은 것을 수락
:
을 나는 목록 custs을을 ...; 크기가 100이고 CreateCustomers (custs)를 호출하십시오. 20은 나쁘지 만, 이유에 대한 정보를 제공합니다. 내 데이터 입력 점원 오타가 많이 나오게합니다. 문제가 해결되면 CreateCustomers (custs)를 다시 시도하지만 그 중 80 개가 이미 존재한다는 오류가 발생합니다. 당신은 여전히 고정되어있는 20 개를 만들었습니까 (왜냐하면, 마지막으로 데이터를 전달했기 때문입니까?).
모든 트랜잭션을 원 자성으로하는 것이 큰 이점은 무언가가 작동하지 않으면 작동이 실패한 후 상태가 변경되지 않았다는 것을 확실히 알 수 있다는 것입니다.
안녕 SnOrfus. 매우 유효한 포인트를 테이블에 가져옵니다. 나는 원자 모델의 전부 또는 일부를 사용하기로 결정했습니다. 감사합니다. 스티븐 – stevenrosscampbell
설명 된 시나리오에서는 WCF에서 오류 (faultcontract)를 관리하는 방법이 나와 있습니다.
모든 방법을 사용하면 하나 이상의 고객 요청에 오류가 있음을 간단하게 설명 할 수있는 faultcontract를 작성해야합니다.
이 방법을 사용하지 않으면 각 가능한 오류를 처리하고 목록의 각 오류에 대해 구분하는 방식으로 datacontract/faultcontract를 디자인 할 수 있습니다. 또한 왕복 여행에서 중복 항목을 정상적으로 처리하기를 원합니다.
안녕하세요. 조언 해 주셔서 감사합니다. 나를 혼란스럽게 한 것은 클라이언트에게 오류를 일으킨 레코드를 알려주는 방법 이었지만 귀하의 권리는 기본 식별자를 제공하여 알려줄 수 있다는 것입니다. 빠른 후속 질문입니다. 예를 들어, 8 명의 고객이 전달되고 첫 번째 고객이 유효성 검사에 실패하면 말하십시오. 그 당시에 고객에게 돌아가시겠습니까? 아니면 다른 기록의 유효성을 계속 확인하여 오류가 있습니까? 감사합니다, 스티븐 – stevenrosscampbell
개인적으로, 나는 그들 모두를 검증하고 모든 검증 오류를 다시 보내 줄 것입니다. 이렇게하면 특히 오류가 발생하기 쉬운 업데이트에서 트래픽을 앞뒤로 줄일 수 있습니다. 다행히 도울 수있어. –