2009-04-20 4 views
1

많은 다른 것들 (읽기 : 요구 사항 없음)에 사용할 수있는 웹 서비스 메서드를 구현해야하며 클라이언트가 인터페이스를 변경할 필요가 없습니다. 메서드는 무엇입니까?WCF 웹 서비스 메서드 조언

[DataContract] 
    public class Status 
    { 
     [DataMember(Order = 0)] 
     public long Code 
     { 
      get; 
      set; 
     } 

     [DataMember(Order = 1)] 
     public string Message 
     { 
      get; 
      set; 
     } 
    } 

[DataContract] 
    public class Data 
    { 
     [DataMember(Order = 0)] 
     public string Name 
     { 
      get; 
      set; 
     } 

     [DataMember(Order = 1)] 
     public string Value 
     { 
      get; 
      set; 
     } 
    } 

public Status InitiateTransaction(long txnTypeId, Data [] txnData); 

생각처럼 가정하면 클라이언트는 "거래"가 시작하려면 어떤 유형에 따라 데이터 배열에 다른 일을 통과 할 것입니다. 특정 작업을 수행하는 다양한 특수 방법을 만드는 것 이상의 이점은 무엇입니까? .에서 전달되는 내용에 따라

하지만 동시에 너무 그것의 가장 큰 약점, - 그것은 다소 "일반"의 -

답변

2

당신이 이것을 구현할 것을 제안하는 사람들이 부끄러움을당하는 경우,이 패턴이 게으름의 확실한 신호라고 말해주십시오. 행동에 필요한 요구 사항을 파악하기 위해 신경 쓸 수 없으므로 단일 메서드를 지정합니다. 데이터 요구 사항을 파악하는 데 신경 쓸 수 없으므로 이름/값 쌍을 결정합니다.

이런 종류의 것이 유용하다는 것을 알게 된 유일한 상황이 있습니다. 필자는 XML 조각을 받아들이고 적어도 XML 스키마에 의해 제약을받는 XML 조각을 반환하는 웹 서비스를 정의 할 때 가치있는 것을 보았습니다. 이것은 서비스가 XML 문서와 관련하여 작동하는 다른 서비스 나 다른 코드와 상호 작용할 때 사용됩니다. 예를 들어 EDI 시나리오는 문서 형식이 업계 표준이나 계약에 의해 이미 정의되어 있고 웹 서비스가 실제 작업을 수행 할 서비스의 프록시 일뿐입니다.

예를 들어 그 변명이 보이지 않습니다.

1

음, 혜택입니다. 그것이 너무 포괄적이고 다목적이기 때문에 실제로 많은 제약과 유효성 검사를 시행 할 수는 없습니다.

웹 서비스, 데이터베이스 스키마 등 여러 가지 방법으로이 접근법을 보았습니다. 일반적으로 두 개 또는 세 개의 "사물"에 대해 잘 작동하지만 더 복잡해지기 시작합니다.

내가하고 싶은 일에 대해 구체적이고 잘 검증 된 방법을 만드는 것이 좋습니다.

마크가

PS :도 - 클라이언트에 변화없이 매우 쉽게 수행 할 수 있습니다 기존의 인터페이스 중 하나를 변경하지 않는 동안도 추가 방법과 기존 서비스를 확장 - 그래서 당신은 항상 쉽게 확장 할 수 있습니다 서비스가 필요에 따라 확장 될 수 있습니다.

+0

나는 분명히 당신과 동의합니다. 나는 이것이 다른 어떤 개인에게 그것을 증명할 수있는 나쁜 패턴 인 이유를 생각해 내기 위해 노력하고있다. – Nick

1

웹 서비스를 호스팅 할 때도 이러한 종류의 서비스를 이용할 수 있습니다. SOAP 엔드 포인트에서 이것을 호스팅한다면 클라이언트는 웹 서비스를 호스트하기 위해 IIS 나 다른 것이 HTTP 메시지로 해석하고 올바른 HTTP 처리기를 호출하는 "코드"와 "메시지"를 제공합니다. WCF SOAP 처리기는 SOAP 스택이 올바른 서비스 메서드를 호출하고 해당 메시지를 해당 메시지로 전달하는 코드 및 메시지 집합을 포함하는 메시지를받습니다. 그러면 다시 메시지를 열어야합니다. 코드와 메시지를 받고 올바른 것을 호출하십시오.

어느 시점에서든 메소드를 구현해야합니다. 따라서 관리자에게 묻는 질문은 이미 공급자, 표준화 된 메시지 및 기타 메시지 시스템을 사용하지 않는 이유와 그 위에 TOP을 직접 구현하여 시간을 낭비해야하는 이유입니다.

또한 Marc은 기존 클라이언트의 doesn't force any changes 인터페이스에 더 많은 메소드를 추가했습니다.