WCF와 웹 API에 대한 기술 토론은 어떻게 관리합니까?

저는 현재 15 명의 개발자로 구성된 팀을 관리하고 있으며, WCF와 웹 API의 사용에 대해 토론하면서 팀이 완전히 반대되는 두 팀으로 나뉘는 기술을 선택하는 데 어려움을 겪고 있습니다.

웹 API 사용을 지원하는 팀 A는 다음과 같은 이유를 제시합니다.

1. 웹 API는 현대적인 서비스 작성 방법입니다 ( Wikipedia )
2. WCF는 HTTP에 대한 오버 헤드입니다. TCP, Net Pipes 및 기타 프로토콜을위한 솔루션입니다.
3. [DataContract] 및 [DataMember] 및 해당 속성으로 인해 WCF 모델은 POCO가 아닙니다.
4. SOAP는 JSON만큼 읽기 쉽고 편리하지 않습니다.
5. SOAP는 JSON과 비교하여 네트워크에 대한 오버 헤드입니다 (HTTP를 통한 전송)
6. 메소드 오버로드 없음

WCF 사용을 지원하는 팀 B는 다음과 같이 말합니다.

1. WCF는 구성을 통해 여러 프로토콜을 지원합니다
2. WCF는 분산 트랜잭션을 지원합니다
3. WCF에 대한 많은 좋은 예와 성공 사례가 있습니다 (웹 API는 아직 어리지만)
4. 양방향 통신에 탁월

이 논쟁은 계속되고 있으며 지금 무엇을해야할지 모르겠습니다. 개인적으로, 우리는 올바른 사용 장소에만 도구를 사용해야한다고 생각 합니다 . 다시 말해, HTTP를 통해 서비스를 노출하고 싶지만 TCP 및 이중에 대해서는 WCF를 사용하려면 웹 API를 사용하는 것이 좋습니다.

인터넷을 검색하면 확실한 결과를 얻을 수 없습니다. WCF를 지원하기위한 많은 게시물이 있지만 그 반대의 경우도 있습니다. 이 질문의 본질은 논쟁의 여지가 있지만, 결정을 내릴 좋은 힌트가 필요하다는 것을 알고 있습니다. 우연히 기술 을 선택 하면 나중에 후회하게 될지도 모릅니다. 열린 눈으로 선택하고 싶다.

우리의 사용법은 주로 웹용이며 HTTP를 통해 서비스를 노출합니다. 경우에 따라 (예 : 5-10 %) 분산 트랜잭션이 필요할 수 있습니다.

지금 어떻게해야합니까? 이 토론을 건설적인 방법으로 관리하려면 어떻게해야합니까?

양측이 좋은 주장을하고 문제에 대한 의견이 합의에 도달하기에는 너무 강할 때, 관리자로서 당신은 결정을 내리고 토론을 끝내야합니다. 그렇지 않으면 그것은 단지 원형으로 바뀌고 모든 참가자의 위치를 ​​더욱 강화시킬 것입니다. 기다릴수록 "잃어버린"쪽이 패배를 인정하고 그 결과로 생산적으로 일하는 것이 더 어려워집니다.

모든 주장을 기록하고 프로젝트의 중요성을 평가 한 다음 결정하십시오. 할 수 없으면 동전을 뒤집습니다. 두 기술 중 하나를 사용하여 프로젝트를 성공적으로 완료 할 수 있으며 불필요한 토론으로 소중한 시간을 낭비하면 불필요한 비용이 발생합니다.

모든 주장에서 양측이 100 % 정확하다고 가정하면 어떤 것이 중요합니까?

[DataContract] 및 [DataMember] 및 해당 속성으로 인해 WCF 모델은 POCO가 아닙니다.

신경 쓰세요? POCO가 필요한 작업을 계획하고 있습니까?

WCF는 분산 트랜잭션을 지원합니다

다시 말하지만 이것은 다른 길을 택했기 때문에 사용하려고하고 그것을 가지고 있지 않은 경우 빌드해야합니까?

기본적으로 다음 중 하나의 핵심에 도달하십시오.

• 필요한 모든 것을 제공합니다 (필요한 모든 것을 제공하지 않으면 최소한의 작업을 수행해야 함).
• 당신이 사용하지는 않지만 어쨌든 참 아야 할 최소한의 쓰레기를 제공합니다.

달성해야 할 경로에 있지 않은 모든 주장은 관련이 없으며 결정에 영향을 미치지 않아야하며 향후 확장을 고려할 수있는 약간의 여지가 있습니다.

내 두 센트를 넣어

관리자는 팀원에게 Yagni 원칙 을 명심하도록 요청해야합니다 . 이렇게하면 두 팀이 제기 한 이유 목록을 줄이는 데 도움이됩니다.

우리의 사용법은 주로 웹용이며 HTTP를 통해 서비스를 노출합니다. 경우에 따라 (예 : 5-10 %) 분산 트랜잭션이 필요할 수 있습니다.

분산 트랜잭션에 뛰어 들기보다는 대신 보상 작업을 고려해야 합니다.

마지막으로 고려해야 할 것은 학습 곡선입니다. 프로젝트 마감일에 따라 관리자는 새로운 기술 학습을 시작할지 여부를 결정할 수 있어야합니다.

낭비 할 시간이 충분하다면 팀 A와 B가 같은 요구 사항에 따라 개념 증명을 생성 할 수있는 혁신 의 날을 보내십시오.

그런데 " [DataContract] & [DataMember] 및 해당 속성으로 인해 " WCF 모델은 POCO가 아닙니다 "라고 말하는 사람에게 POCO 는 일반적으로 도메인 엔터티를 의미하며 노출하는 것이 가장 좋은 방법은 아니라고 말합니다 모든 종류의 클라이언트에 대한 도메인 객체. 이것이 DTO의 목적입니다.

지금 어떻게해야합니까? 이 토론을 건설적인 방법으로 관리하려면 어떻게해야합니까?

먼저 주관을 멀리하십시오. WebAPI 팀의 주장에 따르면 "웹 API는 현대적인 방법입니다" *, "그 속성으로 인해 WCF 모델은 POCO가 아닙니다" 및 "SOAP는 JSON만큼 읽기 쉽고 편리하지 않습니다"라는 평범한 잘못이 아니라고 생각합니다. 의사 결정에 도움이되지 않습니다.

따라서해야 할 일 : 서비스 로 무엇을하고 싶은지 결정한 다음, 최소한의 고통으로 그 목표와 그 유지 관리 성과 확장 성을 수용 할 수있는 기술을 선택하십시오. 주어진 양상이 사용할 프레임 워크에서 지원되는지 여부를 간단히 조사하면됩니다.

재미있는 독서 자료 :

• Mvc 4 및 Wcf 웹 API
• WCF 또는 ASP.NET 웹 API? 주제에 대한 내 두 센트
• WebAPI 또는 WCF?

참고 : " Web 2.0 웹 응용 프로그램은 SOAP 기반 웹 서비스를 사용하는 SOA (Service-Oriented Architecture)에서 RESTful 웹 자원의보다 일관된 콜렉션으로 이동했습니다 " 라는 인용에 대해서는 Wikipedia를 참조하십시오 . 이는 웹 페이지에서 서비스를 사용할 때 사용하는 예입니다. WebHttpBinding을 사용하여 WCF로 쉽게 수행 할 수도 있습니다. "WebAPI 사용" 이라고 표시되지 않습니다 .

이 질문이 "토론을 관리하는 방법"을 넘어서는 경우 : 메타 데이터를 사용하여 놀랍도록 쉽게 강력한 클라이언트 유형을 생성 할 수 있기 때문에 웹이 아닌 클라이언트가 서비스를 사용하려면 WCF를 사용합니다.

팀 관리는 제쳐두고 다른 것을 선택하지는 않습니다. 각 웹 서비스의 목적을 살펴보고 응용 프로그램의 특정 부분에 적합한 기술을 사용해야합니다. 팀이 엔티티 프레임 워크를 사용할 때 상점 프로 시저를 금지하는 것과 같습니다.

우리의 사용법은 주로 웹용이며 HTTP를 통해 서비스를 노출합니다. 경우에 따라 (예 : 5-10 %) 분산 트랜잭션이 필요할 수 있습니다.

그런 다음 WCF에서 5 ~ 10 % 웹 서비스를 작성하십시오. 다른 프로젝트에서 서비스를 내부적으로 참조해야하는 경우에는 논쟁의 여지가 없습니다. 클라이언트 프록시를 생성하기 위해 WCF 계약을 가져 오는 기능의 장점은 논의 할 여지가 없습니다. 전체 통합, 효율성 및 유형 안전을 완전히 새로운 수준으로 끌어 올립니다.

Asp.net 웹 API에서 공개 API (아마도) / Ajax 요청에 사용될 내용을 작성합니다.

페이지 전용 아약스 호출 인 경우 Asp.Net MVC를 사용할 수 있습니다.

선택하지 말고 모두 포용하십시오. WCF와 Asp.net 웹 API는 서로 다른 용도로 사용됩니다. 과일 샐러드에 사과와 오렌지를 모두 먹을 수 있다고 말하는 사람은 없습니다. 하나를 다른 하나를 선택하고 매 시나리오마다 내리는 것은 단지 게으름입니다.

우리 팀도 몇 달 전에 비슷한 토론을했습니다. 우리의 결정 요인은 각 기술을 어떻게 만들고 구현할 것인지에 달려있었습니다. 우리는 이미 MVC 애플리케이션을 구축하고 데이터 바인딩에 Knockout.js를 사용하고 있었기 때문에 컨트롤러는 데이터 용 API 인 MVVM을 효과적으로 사용하고있었습니다.

이를 통해이 프로젝트에서 기술 사용을 다음과 같이 분류 할 수있었습니다.

• 웹 API는 녹아웃 및 Ajax 호출을위한 API로 사용되어 MVVM 패턴에 대한 명령이됩니다. 웹 애플리케이션을위한 비즈니스 로직은 여러 클래스와 리포지토리 및 팩토리를 통해이 계층 뒤에 쌓입니다.
• 그런 다음 WCF는 데이터 저장소에 사용되어이 웹 사이트뿐만 아니라 노출 된 데이터를 소비 한 다른 사이트 나 서비스를 위해 데이터베이스에서 데이터를 노출합니다.

이것이 대중적이거나 과도하게 기술적 인 답변이 아닐 수도 있지만, 먼저 필요한 것과 기술이 어떻게 도움이되는지 결정하는 것은 팀이 어느 기술을 어디에 사용할 것인지 결정하는 데 도움이됩니다.

다시 말해, HTTP를 통해 서비스를 노출하고 싶지만 TCP 및 이중에 대해서는 WCF를 사용하려면 웹 API를 사용하는 것이 좋습니다.

이것이 가장 합리적인 접근 방식입니다. WCF와 WebApi 서비스를 동일한 웹 응용 프로그램에서 서로 다른 용도로 사용하는 것이 일반적입니다.

몇 가지 주장 만 수정하면됩니다.

[DataContract] 및 [DataMember] 및 해당 속성으로 인해 WCF 모델은 POCO가 아닙니다.

많은 경우 WCF 모델은 데이터 계약 / 데이터 멤버 속성 없이 작동 합니다.

SOAP는 JSON만큼 읽기 쉽고 편리하지 않습니다.

사실은 아니지만 WCF 웹 서비스는 일반적으로 팽창 된 SOAP가 아닌 일반 XML을 전달합니다. 이것은 확실히 이다 읽을.

WCF에 대한 한 가지 주장 : 사용 가능한 WSDL이있는 경우 거의 모든 기술에는 메타 데이터에서 프록시를 생성 할 수있는 수많은 도구가 있습니다. 반면에 JSON 스키마는 아직 널리 지원되지는 않습니다.

WCF 데이터 서비스와 함께 줄을 서십시오. 멋진 OData / webapi 스타일 쿼리 및 WCF의 강력한 기능과 유용성, 제대로 반환하는 기능 JSON. 또한 다음과 같은 멋진 자동 wcf 호스팅 코드가 있으면 Wcf가 그렇게 나쁘지 않습니다.

https://github.com/ImaginaryDevelopment/MvcOdata

WebApi프론트 엔드와 WCF data services중간 계층에서 사용하려고 할 때 WebApi문자열 포함 또는 문자열 일치 odata 연산자와 같은 간단한 것들에 던져 졌다는 점을 제외하고는 완전히 분리되지 않았다고 말하고 싶습니다 .

훌륭한 설계자는 기술 결정이 반드시 필요할 때까지 지연됩니다.

다시 말해서 클라이언트가 실제로 연결해야 할 때까지 결정하지 마십시오. 실제로 전송 / 통신 메커니즘을 적용하지 않고 완전히 테스트 된 서비스 계층을 구축 할 수 있습니다. 작업의 95 % 이상이 프레임 워크 외부의 어댑터 아래에서 수행 될 수 있습니다.

이러한 서비스를 원격 클라이언트에 공개 할 때가되면 가장 최신의 프레임 워크를 선택하고 다양한 서비스 계층에 얇은 래퍼를 작성할 수 있습니다.

"실제"서비스 계층이 제대로 수행되면 최소한의 비용으로 여러 래퍼를 사용해 볼 수도 있습니다.

어쨌든 그것은 교의적인 대답입니다. 실제로 , 초기 및 빈번한 통합 테스트를 용이하게하기 위해 선반 에서 가장 간단한 도구 를 선택할 수도 있지만, 여전히 의존성을 제한 하고 실제 서비스에 대한 단순한 통신 계층 으로 엄격하게 취급합니다 .

이 접근 방식을 취하면 처음에는 사용할 가장 간단한 도구를 선택하게되며 , 필요한 경우 나중에 최소한의 노력 으로 더 정교하거나 트렌디 한 도구 또는 프레임 워크를 구현할 수 있다는 사실을 팀이 알고 있기 때문에 어려울 것 입니다.

따라서 나는 지금 같은 선택에 직면하고 있으며, 현재 우리 팀이 사용하는 WCF의 기능 중 일부 가 무엇인지 스스로에게 물었습니다 . 다른 프로토콜을 사용합니까? 아니요. 거래 지원을 사용합니까? 아니요 (맞춤형 최종 일관성 메커니즘을 사용하더라도). 듀플렉스를 사용합니까? 아니.

왜 웹 API를 사용하고 싶습니까? 보다 쉬운 프론트 엔드 통합 (현재 존재하는 추가 서비스 계층 제거), 클라이언트에게 응답을 푸시하기위한 SignalR, GET 캐싱

아마도 다른 이유를 찾을 수있을 것입니다. :) 또한 WCF를 유지해야하는 이유입니다.

내가 당신의 위치에 있다면 나는 당신의 팀 능력을 검사하는 것으로 시작할 것입니다. 팀의 모든 사람이 이미 WCF를 알고 있고 적은 비율 만 웹 API를 알고 있다면 이미 결정한 것입니다.

반드시 시간이 있다면 지식 기반을 배우고 개선하는 데 투자해야하지만 비즈니스 요구와 회사 생산성을 희생하지는 마십시오.

어떤 상호 작용 모델을 지원해야하는지 묻고 싶습니다. 원하는 외부 인터페이스가 RPC 또는 REST와 더 비슷합니까? 내 경험상 그것은 대개 어딘가에 있지만 대부분 하나 또는 다른 것입니다.

.Net의 다른 프로젝트에 대한 자체 서비스를 사용하고 있습니까? 이것은 아마도 당신이 요청할 수있는 가장 눈에 띄는 질문 일 것입니다. WCF는 인터페이스를 별도의 클래스 라이브러리로 추상화하고 클라이언트를 빌드하고 주입 할 수 있다는 이점이 있습니다. 이에 대한 확장으로 JSON 및 SOAP / WSDL 엔드 포인트를 모두 사용하여 WCF 기반 프로젝트를 마운트 할 수 있습니다. WCF는 또한 정의 된 인터페이스에 대해 더 나은 보증을 제공합니다.

즉, 일반적으로 다른 플랫폼의 XML 클라이언트를 가질 것으로 예상되는 경우 SOAP는 단순한 JSON 끝점보다 측정 가능한 오버 헤드가 아닙니다. JSON / Web API 라우트를 사용하는 경우 엔드 포인트 및 API와 상호 작용하는 방법을 문서화하는 데 훨씬 능숙해야합니다.

일반적으로 데이터 제출 방법과 단일 요청 객체 구조에 대한 응답을 원하는 방법을 설명하는 간단한 API 문서를 작성하는 것이 좋습니다. 테스트 케이스를 가장 보편적 인 방식으로 작성하고 문서화하십시오. 간단한 curl 문을 추천합니다. 그런 다음 여러 멤버가 WCF 및 웹 API를 사용하여이를 구현하도록하십시오. 그런 다음 어느 승리를 참조하십시오.

개인적으로 WCF를 사용하여 비교적 큰 프로젝트와 구현을 수행했지만 실제로 실제로는 오류 조건을 처리하기 위해 JSON 결과와 Global.asax.cs의 일부 재정의 동작을 사용하는 WCF 인 가장 간단한 구현에 의존합니다. API 문서에 curl 문이 포함되어 있고 curl 예제를 사용하여 API의 모든 기능을 사용할 수 있으면 웹 인터페이스를 지원하는 모든 언어로 클라이언트를 구현하기가 훨씬 쉬워집니다. 이것은 실제로 WCF가 떨어지기 시작하는 곳입니다. 외부 시스템을 다룰 때 자동화 된 툴링으로 구조를 갖추는 것보다 독립적으로 정의 된 API를 사용하는 것이 좋습니다. 다른 플랫폼에서 이러한 시스템의 소비자로 말하십시오.

그 너머의 한 가지는 클라이언트를 두 가지 다른 언어로 구현하는 것입니다. C #에서 클라이언트를 수행하고 Node.js 또는 Python에서 클라이언트를 수행하고 실제로 얼마나 적합한 지 확인하십시오. 그 운동만으로도 API의 느슨한 끝을 털어 낼 수 있습니다.