문제

나는 WCF를 배우려고 노력하는 동안 충분히 직접적으로 보이지만 이상한 상황을 겪었습니다. 적어도 나에게는 이상해 보입니다.

ServiceHost CTOR가 구체적인 클래스를 수강하고 AddServiceEndpoint가 인터페이스를 취하는 이유는 무엇입니까? 후자는 OOP 관점에서 더 논리적 인 것 같습니다.

다음을 고려하세요:

    [ServiceContract]
    interface IVocalAnimal
    {
        [OperationContract]
        string MakeSound();
    }
  ...      
  public class Dog : IVocalAnimal
  {
     public string MakeSound()
     {
        return("Woof!");
     }
  }
 ...
 public class Cat : IVocalAnimal
  {
     public string MakeSound()
     {
        return("Meeooow!");
     }
  }

이제 우리는 개를 통해 개나 고양이의 소리를 얻기 위해 연결할 수있는 "동물 사운드"서비스를 만들고 싶어합니다.

...
Uri baseAddress = new Uri("net.pipe://localhost/AnimalSoundService");
ServiceHost serviceHost = new ServiceHost(typeof(IVocalAnimal), baseAddress);
serviceHost.AddServiceEndpoint(typeof(Dog), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "Dog");
serviceHost.AddServiceEndpoint(typeof(Cat), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "Cat");
...

그러나 위의 코드는 내가 이해하지 못하는 이유와 같이 컴파일하지 않을 것입니다. ServiceHost CTOR는 콘크리트 클래스 (개 또는 고양이)를 원하고 엔드 포인트는 인터페이스를 원합니다.

따라서 미세한 세분화 엔드 포인트가 특정 구현을 지원하는 것이 더 자연 스럽기 때문에 그 반대의 이유는 무엇입니까 (따라서 엔드 포인트 주소 당 계약의 특정 구현에 도달 할 수 있음). 인터페이스를 수락하려면?

BTW, 나는 pedantic이 아닙니다 .. 나는 여기서 무언가를 놓친 것이 내가 확신하기 때문에 정직하게 이해하려고 노력하고 있습니다.

도움이 되었습니까?

해결책

ServiceHost를 만들 때 실제 서비스를 작성하므로 콘크리트 여야합니다.

반면에 귀하의 엔드 포인트는 고객이 보는 것입니다. 고객이 반드시 구현을 알고 싶어하는 것은 아닙니다. 인터페이스 정의 만 가져와야합니다.

엔드 포인트는 귀하가 말하는 것처럼 특정 구현을 지원합니다. 엔드 포인트의 목적은 여러 구현을 제공하는 것이 아니라 단일 구현에 액세스하기 위해 여러 프로토콜/바인딩을 제공하는 것입니다.

독특한 개와 고양이 서비스를 원한다면 각각 하나의 NetNamamePipeBinding 엔드 포인트가있는 두 개의 서비스 호스트가 필요하다고 생각합니다.

다른 팁

나는 당신이 생각하는 것을 봅니다. OOP 관점에서 의미가 있지만 서비스 관점이 아닙니다. 서비스는 운영 그룹입니다. 해당 운영 그룹은 계약에 정의됩니다. 클래스를 사용하여 서비스 계약을 모델링 할 수 있지만 인터페이스가보다 직접적인 모델이기 때문에 대부분의 인터페이스를 사용합니다. MSDN은 a 아주 좋은 토론 그 개념의.

당신은 나를 모르고 나는 당신을 모른다는 것을 기억하십시오. 우리는 객체가 아니라 메시지를 교환합니다. 나는 당신에게서 고양이와 개를 원하지 않습니다. 우리가 사전 합의가 없다면 고양이 나 개와 함께 무엇을 해야할지 모르겠습니다. 당신은 내가 할 수있는 일을 말해주고 당신에게 방법을 호출하여 그것을합니다. 여기에 있습니다 좋은 기사 내부의 데이터와 외부의 데이터.

나는 다른 답변과 조금 동의하지 않아야합니다. 그것들은 어떤 식 으로든 기술적으로 정확하지만, 이것이 구현을 숨기거나 클래스 대 인터페이스를 사용하여 서비스 계약을 정의하는 것과 관련이없는 가장 중요한 이유를 느낍니다.

단일 서비스 구현이 여러 엔드 포인트를 노출시킬 수 있다는 사실을 고려할 때 왜 그런지 더 분명합니다. 각 엔드 포인트는 다른 계약을 노출 시키거나 노출하지 않을 수도 있고, 각 계약은 당신이 아는 모든 계약에 노출 될 수 있습니다.

예를 들어, MSMQ에 대한 단방향 계약과 HTTP에 대한 양방향 계약을 노출시키는 서비스가있을 수 있습니다. 또는 아마도 하나의 URL에 JSON 계약과 XML 계약을 노출시킬 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top