2010-08-08 3 views
1

저는 WCF를 통해 백엔드 서비스와 통신하는 Silverlight 프론트 엔드로 응용 프로그램을 빌드하고 있습니다. 내 서비스에는 프론트 엔드와의 모든 핵심 통신을 처리하는 인터페이스가 있습니다.플러그인을 사용하여 WCF 인터페이스 확장

백엔드는 다양한 플러그인으로 확장 될 수 있으며 프리즘으로 이러한 플러그인을 구성하기위한 맞춤형 실버 라이트 모듈을로드 할 계획입니다. 문제는 이러한 플러그인이 기본 WCF 인터페이스의 일부가 아닌 추가 기능을 추가한다는 것입니다. 내 모든 통신 (즉, 추가 라우터 구성 필요 없음)에 대해 단일 종점을 유지하고 싶습니다.

이 구현에 접근하는 방법에 대한 몇 가지 아이디어를 찾고 있습니다. 내 "최고의"생각은 현재 핵심 인터페이스에서 함수 이름과 매개 변수 목록을 받아들이고 함수를 사용하여 특정 플러그인을 호출하는 기능을 찾는 것입니다. 나는이 것을 좋아하지 않습니다. 많은 이유들로 인해.

단일 끝점에서 확장 가능한 WCF 인터페이스를 작성하기위한 권장 사항은 무엇입니까?

감사

답변

3

나는 이것이 일반적으로 처리하는 두 가지 방법을 생각할 수 있습니다

  1. XML 계약 - 기본적으로, 서비스는 XML 반환 값을 가진 XML 매개 변수에 불과,이된다 없습니다. 그런 다음 클라이언트와 서버 간 명령을 파싱하거나 직렬화/역 직렬화 할 수 있습니다. 귀하의 계약은 단일 XML만을 제공하기 때문에 "내부"에서하는 일은 귀하에게 달렸습니다. 클라이언트에서 생성 된 호출을 검증하는 새로운 메소드에 대한 스키마 전송과 같은 작업을 수행 할 수 있습니다.

  2. RESTful 서비스 - RESTful 서비스. REST 계약은 URL이므로 새 URL 형식을 제공하는 것만 큼 새 확장을 추가하는 것이 간단합니다. 확장 메서드에 대한 새 호출을 호출하고 응용 프로그램을 빌드 할 때이를 관리하는 방법을 포맷터를 통해 클라이언트에 전달할 수 있습니다.

현실적으로, 그러나, 당신의 글꼴 엔드 서버 측 확장 모든 가장자리 케이스를 처리하고 동적으로 새로운 화면과 검증을 구축 할 수있을 것입니다 의심한다. 이 경우 더 나은 접근 방식은 MEF를 사용하여 Silverlight 응용 프로그램을 모듈 응용 프로그램으로 구성하는 것입니다. 서버에 확장 기능이 있으면 클라이언트에 확장 기능 XAP를 제공하기 만하면됩니다. 서버가 XAP 파일을 플러그인 용 디렉토리에 열거하고이를 Silverlight 응용 프로그램에 보내면 새 응용 프로그램이 사용 가능 해지면이를 동적으로로드 할 수 있습니다. XAP에는 확장 기능에 대한 새로운 WCF 계약에 연결하는 코드가 포함됩니다.

+0

감사합니다. 정확하게 내가 찾던 조언입니다. 프론트 엔드에 MEF를 사용할 계획이었고 XML 또는 REST 둘 다 좋은 선택처럼 보였다. – Aaron

관련 문제