요청/응답 패턴은 일부 기업과 같은 프로젝트에서

Question

은 (WCF .NET) 나는 모든 서비스 계약은 단일 Request 매개 변수를 받아 항상 Response 돌아 보았다 ErrorCode, Context 등. 서비스 메소드와 프록시의 본문은 try/catch로 래핑되므로 오류를 확인하는 유일한 방법은 ResponseBase.ErrorCode (열거 형)입니다.

이 기술이 어떻게 호출되는지, 그리고 메서드 매개 변수로 필요한 것을 전달하고 표준 WCF 컨텍스트 전달/오류 메커니즘을 사용하는 것과 비교할 때 더 좋은 이유를 알고 싶습니다.

Answer 1

귀하가 말하는 패턴은 계약 우선 개발을 기반으로합니다. 그러나 WCF에서 Error 블록 패턴을 사용할 필요는 없지만 Error Xml 블록을 사용하는 대신 faultexceptions을 클라이언트에 다시 throw 할 수 있습니다. 오류 블록은 오랜 기간 동안 사용되어 왔으며, 따라서 많은 사람들이 사용에 익숙합니다. 또한 다른 플랫폼 개발자 (예 : java)는 업계 표준 임에도 불구하고 faultExceptions를 잘 알고 있지 않습니다.
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

요청/응답 패턴은 SOA (서비스 지향 아키텍처)에서 매우 가치가있다, 나는 그것을 사용하는 대신 매개 변수를 받아 값이나 개체를 다시 전달 방법을 만드는 것이 좋습니다. 메시지 작성을 시작할 때 이점이 나타납니다. 이전에 언급했듯이 XSD를 사용하여 먼저 메시지를 만들고 XSD를 기반으로 클래스를 생성하는 Contract First Development에서 발전했습니다. 이 프로세스는 기존 웹 서비스에서 모든 데이터 유형이 SOAP에서 올바르게 직렬화되도록하기 위해 사용되었습니다. WCF의 출현으로 datacontractserializer는보다 지능적이며 이전에 제대로 직렬화되지 않은 유형 (예 : ArrayList, List 등)을 직렬화하는 방법을 알고 있습니다. 요청 - 응답 패턴의

장점은 다음과 같습니다

• 에서는 일반적인 속성에 대한 일관성 (예를 들어 에러 블록)을 유지 할 수있는 당신은 당신의 요청 및 기본 객체에서 모든 응답을 상속 할 수 있습니다.
• 웹 서비스는 가능한 한 적은 수의 문서를 필요로합니다. 이 패턴은 바로 그것을 허용합니다. 예를 들어 public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request);과 같은 메소드를 가져옵니다. 클라이언트는 기본적으로 전달할 대상과 반환하는 대상을 알 수 있으며, 요청을 작성할 때 필요한 대상과 선택 사항을 볼 수 있습니다. 이 요청에 Carriers [플래그 열거 형] (필수), StartDate (필수), EndDate (필수), PriceRange (옵션), MinSeatsAvailable (옵션) 등의 속성이 있다고 가정 해보십시오.
• 사용자가 응답을 받으면 일반 반환 개체보다 훨씬 많은 데이터를 포함 할 수 있습니다. 오류 블록, 추적 정보, 무엇이든, 당신의 상상력을 사용하십시오.
  BusScheduleResponse 예에서 여러 캐리어에 대해 여러 버스 일정 정보 배열을 반환 할 수 있습니다.

희망이 도움이됩니다.

한 단어의주의. 혼란스러워하지 말고 자신의 [MessageContract]을 생성하는 것에 대해 이야기하고 있다고 생각하십시오. 요청 및 응답은 DataContracts입니다. 나는 너를 혼란스럽게하지 않기를 바랄 뿐이다. WCF에서 자신 만의 MessageContracts를 만들어야하는 사람은 아무도 없습니다.