웹 서비스는 주로 래퍼 메소드로 구성 될 수 있습니다. 간단한 경우를 타고 ...
어셈블리에 API 방법은
public void DoFoo(string bar)
그런 다음 웹 API 방법 (예 등 WebAPI, ASMX 웹 서비스로 구현의 선택,) 모양을 경우
public void DoFoo(string bar) {
// ... initialization or validation
try {
refToDll.DoFoo(bar);
} catch (Exception e) {
// implementation specific return of error.
}
}
정적 메서드 또는 기본 형식을 사용하는 메서드가 대부분있는 경우보다 쉽게 처리 할 수 있습니다. API에 유형이 정의되어 있으면이 작업이 더 어려워집니다. 형식 시그니처를 변경하고 메서드를 다시 구현해야합니다. API가 없으면 구체적인 제안을하기가 어려울 수 있습니다. 그러나 몇 가지 옵션이 있습니다. 가지고 있다면
public class BazClass {
public string GetScore() {
return scores.Sum();
}
}
기본적으로 원격 쪽 (웹 API)이 클라이언트 측의 컨텍스트를 재구성 할 수 있어야합니다. 직렬화 가능한 인스턴스 또는 BazClass
의 다른 표현을 전달해야하며 원격 API가 작동하도록해야합니다. 그렇지 않으면 존재하지 않습니다. 또한 서버에 상태를 저장하는 많은 메소드를 만들 수 있으며 클라이언트 측 또는 객체 참조에서 "핸들"을 사용하여 작업 할 수 있습니다.하지만 이는 디자인 결정이어야합니다 (기본 라이브러리와의 상호 작용을 살펴보고 처리하고 교차 네트워크로 변환). 예 :
public string BazGetScore(Transport.BazClass baz) {
// Depending on the framework and class (all public getters/setters)?
// your framework may allow for transparent serialization
BazClass bazReal = bazFactory(baz);
string score = bazReal.GetScore();
return score;
}
원본 API가 인터페이스를 기반으로하는 양은 어느 정도입니까? 이로 인해 최종 사용자에게 Proxy 클래스를 훨씬 더 투명하게 만들 수 있습니다. 당신이
public class Baz : IBaz { ... }
이있는 경우 다음 당신은 로컬 행동하는 대신 원격 API를 그냥 IBaz
같은 역할을하지만, 호출하는 프록시 클래스를 생성 할 수 있습니다. 프레임 워크 및 툴링에 따라 툴을 사용하여이를 촉진 할 수 있습니다.
namespace RemoteAPIProxy {
public class Baz : IBaz {
public string GetScore() {
// initialization of network, API, etc
Transport.Baz baz = new Transport.Baz.From(this);
string score = CallRemoteAPI("BazGetScore", baz);
return score;
}
}
}
요약하면 상태, 비공개 방법 또는 전체 범위를 지원해야하는지에 따라 중간 클래스를 만들어야 할 수 있습니다. "방법"은 대부분 다른 래퍼로 간주 될 수 있지만 와이어를 통해 로컬 API를 원격 API의 컨텍스트에 전달하는 방법을 의식해야합니다. 상태에 대해 인터페이스, 직렬화 헬퍼 및 경량 전송 객체를 사용하여 "접착제"를 돕습니다. 기억하십시오. "API"의 유일한 "I"는 "인터페이스"를위한 것이므로 일부를 가지고 있는지 확인하십시오. 행운을 빕니다!
서비스 속성을 포함 할 수있는 방식으로 메소드를 제공하는 래퍼를 만듭니다. –