WCF 프로젝트 설정 및 종속성

Question

WCF 서비스 프로젝트 및 응용 프로그램을 설정하는 가장 일반적인 방법은 무엇입니까?

• 솔루션 : "MyProject를"
• 클래스 라이브러리 : 여기
  은 예입니다 "MyProject.Common"
  • 가의 ServiceContract 인터페이스를 포함하고, 어떤 DataContracts
• 클래스 라이브러리 : "MyProject.Impl"
  • 는 서비스 계약의 구현 및 서비스를
• WCF 서비스 웹 응용 프로그램을 호출하는 데 사용할 수있는 클라이언트 클래스를 포함합니다 : MyProject.Common 및 IMPL에 "MyProject.Service"
  • 은 참조를 포함을, "MyProject.Web" :이 서비스를 호스팅 할 수 있도록
  • WCF 서비스 응용 프로그램의 Web.config에
• ASP.NET 웹 응용 프로그램을 끝점을 구성합니다
  • 는 등의 Web.config에서 엔드 포인트를 구성 할 필요가있다 "MyProject.Common"와 "MyProject.Impl"는 클라이언트 클래스를
  • 웹 응용 프로그램을 사용할 수 있습니다 할 수 있도록 참조를 포함

제 질문은 계약서와 구현을 별도의 DLL로 분할하고 응용 프로그램이 Common/Impl 라이브러리를 참조해야하는지 여부 또는 응용 프로그램이 서비스 참조를 만들어야하는지 여부입니다. ("Create Service Reference"또는 SvcUtil 사용). 나는 앱이 단지 서비스 참조를하는 것이 합리적이라고 생각한다. 그래서 당신은 Common/Impl을 앱에 연결하지 않는다. 이 경우 MyService.Impl에 클라이언트 클래스를 만드는 것이 합리적일까요?

Answer 1

Web Service Software Factory을 확인하십시오. solution structure에 대한 몇 가지 지침을 포함하여 WCF 응용 프로그램을 작성하는 데 유용한 지침이 많이 있습니다. 또한 IDesign.NET (Juval Lowy)은 guidance on that도 있습니다 (우편 번호 링크).

Answer 2

복잡한 유형을 사용하는 경우 클라이언트 응용 프로그램에 서비스 인터페이스와 공통 클래스를 포함해야합니다. 그렇지 않으면 생성 된 프록시가 서비스에서 사용한 유형 정의를 복제하므로 나중에 직렬화로 인해 두통이 발생할 수 있습니다 ...

그런 다음 공용 어셈블리에서 유형을 사용하는 프록시를 수동으로 생성 할 수 있으며 유형을 시뮬레이트하는 다른 클래스를 다시 작성하지 않습니다.

C : 샘플 \ \ WcfSerialization> svcutil.exe에 /out:WcfServiceProxy.cs/D : Schmu rgon.WcfClient.Web /r:Schmurgon.Data.Contracts\Schmurgon.Data.Contracts\bin\debu g \ Schmurgon.Data.Contracts.dll http://localhost:5150/Schmurgon.WcfService.Host/S ervice.svc?WSDL

스위치는 :

/아웃 : PARAM 단순히 출력 프록시 클래스의 이름이다.

/d : 프록시 클래스를 저장할 디렉토리입니다.

/R : 그렇지 않으면 프록시 클래스에 포함된다 유형이 들어있는 어셈블리

[없음] 당신의 WCF 서비스의 주소를 입력합니다.

(이 http://schmurgon.net/blogs/ben/archive/2006/12/17/wcf-proxy-generation-without-types.aspx에서 붙여)

Answer 3

이 달려있다.

일반적으로 생성 된 프록시 클래스로 클라이언트 프로그램에서 WCF 서비스를 호출하기에 충분하므로 클라이언트 라이브러리가 필요하지 않습니다. 물론 예를 들어 계약에서 메시지를 매개 변수로만 지정하고 사용자가 데이터 계약을 사용하지만 상황이 매우 드문 상황이 있습니다.

서비스 구현과 동일한 라이브러리에서 클라이언트 클래스가 필요하다고 생각되면 클라이언트 클래스를 배치합니다. 클라이언트는 서비스 구현 방법, 호출 방법을 알 필요가 없습니다. 서비스. 두 서비스를 함께 배치하면 서비스 구현도 분산됩니다.

데이터 계약에서 사용하는 클래스를 표시하는 경우 휴고 (Hugo)에 의해 언급 된 복합 유형 문제가 발생하지 않습니다. 이는 서비스의 쉬운 버전 관리를 위해 반드시 수행해야합니다.

Answer 4

제 질문은 계약과 구현을 별도의 DLL로 분할하고 응용 프로그램이 Common/Impl 라이브러리를 참조해야하는지 여부 또는 응용 프로그램이 서비스 참조를 만들어야하는지 여부입니다. ("Create Service Reference"또는 SvcUtil 사용). 나는 앱이 단지 서비스 참조를하는 것이 합리적이라고 생각한다. 그래서 당신은 Common/Impl을 앱에 연결하지 않는다. 이 경우 MyService.Impl에 클라이언트 클래스를 만드는 것이 합리적일까요?

빙고 - 당신은 그것을 "얻었다"! 이론적으로 기술적으로 은 공유 어셈블리를 사용하여 계약과 인터페이스를 공유 할 수 있지만 그렇게하지 않을 것을 권장합니다.

먼저 다른 클라이언트 (예 : Java, PHP, Ruby)는 공유 .NET 어셈블리를 사용할 수 없습니다. 그래서 갑자기 그들은 클라이언트와 다른 인터페이스를 사용하여 디버깅하기 어려운 미묘한 변형을 일으킬 수 있습니다.

둘째, SOA는 시스템의 일부를 잘 정의 된 서비스 테두리가있는 별개의 개별 엔터티로 분리하는 것에 관한 것입니다. 어셈블리를 공유하면 피하려고하는 종속성이 생깁니다.

그렇기 때문에 계약 인터페이스를 구체적 구현과 분리할지 여부는 논쟁의 여지가 있습니다. 한 가지 이점은 동일한 인터페이스의 두 번째, 세 번째 구현을 만들거나 다양한 서비스에서 사용되는 별도의 어셈블리에 일반적으로 사용되는 헬퍼 인터페이스가있는 경우입니다. 한 번 더 어셈블리가 실제로 다치게하지 않습니다 - 내 추천은 당신이 당신의 포스트에서 설명한 것처럼 정확하게하는 것입니다!

마크

링크에 대한