WCF / SOA-간단한 요청을 위해 매개 변수 객체를 작성해야하는 이유

우리 회사는 상당히 큰 SOA 이니셔티브를 시작하고 있습니다. 우리는 많은 일을 올바르게하고 있습니다. 의사 소통이 좋습니다. 적절한 도구 비용; 우리는 전환에 도움이되는 좋은 전문 지식을 갖추 었습니다.

우리는 그룹으로 따라갈 수있는 표준을 개발하려고 노력하고 있으며 제안 된 표준 중 하나가 나를 귀찮게합니다.

모든 오퍼레이션이 요청 오브젝트를 가져 와서 응답 오브젝트를 리턴하는 패턴을 표준화했습니다.

나는 이것이 많은 사람들에게 표준적인 접근 방법이라는 것을 알고 있지만 왜 귀찮게해야하는지 묻고있다 . (나는 지혜를 얻지 못해서 이유가 필요하다).

내가 제공 할 대부분의 서비스는 간단한 조직 메타 데이터 검색입니다. 예를 들어 특정 사용자에 대한 보안 정책을 찾으십시오. 여기에는 사용자 아이디가 필요합니다. 표준은이 요청을 객체로 포장하고 반환 된 정책을 응답 객체로 포장해야한다고 알려줍니다.

계약에서 생성 된 WSDL을 살펴보면 불안이 증폭됩니다. WCF는 요청 및 응답 메시지를 자동으로 생성하고 요청 / 응답 개체까지 래핑합니다.

복잡한 요청을하는 경우 복잡한 입력 개체가 필요하다는 것을 완전히 이해합니다. 서비스가 관여하지 않더라도 그렇게 할 것입니다.

내 질문은 다음과 같은 경우 요청과 응답을 자동으로 래핑 해야하는 이유입니다.

• 단순한 서비스를 덜 표현 적으로 만듭니다
• 어쨌든 복잡한 서비스를 위해 그것을 할 것입니다
• WCF는 어쨌든 요청 / 응답 메시지를 작성합니다.

이 접근 방식에 찬성하여 다음과 같은 주장을 발견했습니다.

선택적 매개 변수를 요청 오브젝트에 삽입 할 수 있도록하여 버전 관리를 지원합니다.

그 당시에는 꽤 많은 COM을 만들었으며 버전 관리를위한 거의 반 패턴이라고 생각합니다. 어떤 경우에는 도움이 될 것이라고 생각하지만 도움이되는 곳에서는 이미 매개 변수 객체가 있다고 생각합니다.

일반적인 데이터와 동작을 기본 클래스로 분리 할 수 ​​있습니다.

이것은 나에게 약간의 무게를 가지고 있습니다.

사람들을 RPC 스타일의 행동에서 멀어지게하고 메시징 행동으로

Microsoft 사이트에서이 내용을 읽고 전문가로부터 들었으나 여전히 그것이 무엇을 의미하는지, 왜 가치가 있는지는 확실하지 않습니다. 자연스럽게 보이는 인터페이스는 사람들이 원격 서비스를 호출한다는 것을 잊는 경향이 있습니까?

아마도 300 가지 방법의 시그니처를 리팩토링하는 것을보고 있으므로 이것은 사소한 고통입니다. 나는 구현의 일관성에 대한 열렬한 팬이므로 고통을 기꺼이 감수하고 그것이 결국 가치가 있다는 것을 아는 데 도움이 될 것입니다.

나는 버전 관리가 아마도 가장 좋은 주장이라고 생각합니다. 기존 운영 계약이있는 경우

int GetPersons(int countryId);

예를 들어 나중에 다른 필터로 향상시키려는

int GetPersons(int countryId, int age);

새 운영 계약을 작성해야하며 고유해야하므로 새 이름으로 작성해야합니다. 또는 이전 v1과의 호환성을 위해 여전히 기존 v1을 사용하여 이름을 유지하고 새 v2 서비스를 게시 할 것입니다.

매개 변수를 오브젝트로 랩핑하면 항상 기본 / 선택적 매개 변수를 사용하여이를 확장 할 수 있으며 동일한 작업 계약을 재사용 할 때 기존의 모든 클라이언트에 영향을 미치지 않습니다.

그러나 객체의 이름을 적절하게 지정하고 싶습니다. 그것이 단지 int를 감싸더라도, 당신이 시작 IntMessage하거나 비슷한 것을하면 자신을 확장하는 것을 선호하지 않습니다. 예를 들어 PersonFilter처음부터 바로 이름을 지정해야합니다. 즉,이 서비스 호출이 의미 적으로 매개 변수로 예상해야하는 것과 그에 따라 수행해야하는 것에 대해 약간 생각해야합니다. 올바른 서비스를 개발하고 적절한 크기의 API를 유지 관리하는 데 도움이 될 수 있습니다.

일반적인 데이터와 동작을 기본 클래스로 분리 할 수 ​​있습니다.

그것은 조심해야 할 것입니다. 상속과 데이터 계약은 잘 어울리지 않습니다. 작동하지만 와이어를 통과 할 수있는 계약의 알려진 모든 하위 유형을 지정해야합니다. 그렇지 않으면 데이터 계약 직렬 변환기가 알 수없는 유형에 대해 불평하지 않습니다.

그러나 당신 이 할 수있는 일은 (아직도 아직 결정하지 않았을 것입니다) 다른 서비스간에 동일한 메시지를 재사용하는 것입니다. 데이터 계약을 별도의 dll에 넣으면 클라이언트와 서비스간에 계약을 공유 할 수 있으며 기본적으로 동일한 메시지를 기대하는 다른 서비스를 호출 할 때 유형간에 변환 할 필요가 없습니다. 예를 들어 PersonFilter를 작성하여 한 서비스에 제출하여 개인의 필터 목록을 가져온 다음 다른 서비스에 제출하고 클라이언트에서 동일한 오브젝트를 갖습니다. 나는 그것에 대한 좋은 실제 예를 찾을 수 없으며 위험은 항상 데이터 계약의 확장 이이 계약을 사용하는 모든 서비스에 대해 일반적이지 않다는 것입니다.

전반적으로 버전 관리 외에는 실제로 그렇게하는 데 대한 살인자도 찾을 수 없습니다.

데이터 전송 개체 에 대한 Martin Fowler의 메모 가 여기에 적합하다고 생각합니다.

Remote Facade (388)와 같은 원격 인터페이스로 작업 할 때는 각 호출에 비용이 많이 듭니다. 결과적으로 통화 수를 줄여야하므로 각 통화마다 더 많은 데이터를 전송해야합니다. 이를 수행하는 한 가지 방법은 많은 매개 변수를 사용하는 것입니다. 그러나 이것은 종종 프로그래밍하기가 어려우며 실제로 단일 값만 반환하는 Java와 같은 언어로는 불가능합니다.

해결책은 통화에 대한 모든 데이터를 보유 할 수있는 데이터 전송 객체를 만드는 것입니다. 연결을 통과하려면 직렬화 가능해야합니다. 일반적으로 어셈블러는 서버 측에서 DTO와 도메인 개체간에 데이터를 전송하는 데 사용됩니다.

요청에도 동일하게 적용될 수 있습니다. RPC는 왜 나쁜지 :

자연스럽게 보이는 인터페이스는 사람들이 원격 서비스를 호출한다는 것을 잊는 경향이 있습니까?

나는 그것이 사실이라고 생각하지만 주된 이유는 아닙니다. RPC를 피하는 또 다른 이유는 RPC가 밀접하게 연결된 클라이언트와 서비스를 장려 할 수 있기 때문입니다.