WCFとWeb APIの技術的な議論を管理するにはどうすればよいですか？

私は現在15人の開発者から成るチームを管理していますが、WCFとWeb APIの使用について議論している2つの完全に反対のチームに分かれる技術を選択する段階で立ち往生しています。

Web APIの使用をサポートするチームAは、次の理由を提示します。

1. Web APIは、サービスを記述するための単なる最新の方法です（ウィキペディア）
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には多くの良い例と成功事例があります（Web APIはまだ若いです）
4. デュプレックスは双方向通信に最適です

この議論は継続しており、今何をすべきかわかりません。個人的には、正しい使用場所にのみツールを使用すべきだと思います。言い換えれば、HTTP経由でサービスを公開したいが、TCPとDuplexの場合はWCFを使用する場合は、Web APIを使用した方がよいでしょう。

インターネットを検索しても、確実な結果を得ることができません。WCFをサポートするための多くの投稿がありますが、それどころか、人々がそれについて不満を持っていることもわかります。この質問の性質は議論の余地があるように聞こえるかもしれませんが、決定するにはいくつかの良いヒントが必要です。偶然テクノロジーを選択すると、後悔する可能性があります。目を開いて選びたい。

私たちの使用は主にWebのためであり、HTTP経由でサービスを公開します。場合によっては（たとえば5〜10％）、分散トランザクションが必要になる場合があります。

私は今どうすればいい？この議論を建設的な方法で管理するにはどうすればよいですか？

双方に十分な議論があり、問題に関する意見が強すぎてコンセンサスが得られない場合、マネージャーとしてのあなたは決定を下し、議論を終了する必要があります。それ以外の場合は、単に輪になって、すべての参加者の位置をさらに強化します。長く待つほど、「負けた」側が敗北を認め、結果を生産的に働かせるのが難しくなります。

すべての引数を書き留め、プロジェクトにとっての重要性を評価してから、決定を下します。できないときは、コインを投げます。プロジェクトはいずれかのテクノロジーで成功裏に完了する可能性が高く、不必要な議論で貴重な時間を無駄にすると、不必要なお金が必要になります。

両側がすべての引数で100％正しいと仮定すると、どちらが重要ですか？

[DataContract]＆[DataMember]およびそれらの属性のため、WCFモデルはPOCOではありません

手入れする？POCOが必要なことをするつもりですか？

WCFは分散トランザクションをサポートします

繰り返しますが、これはあなたが使用しようとしているものであり、他の道を進んだために持っていない場合は構築する必要がありますか？

基本的に、どれを中心に考えましょう：

• 必要なすべてを提供します（どちらも必要なすべてを提供しない場合、最小限の作業で済みます）。
• 使用しないジャンクの最小量を提供しますが、とにかく我慢する必要があります。

あなたが成し遂げる必要のある道にない議論は無関係であり、将来の拡張を検討する余地があるため、あなたの決定を考慮すべきではありません。

私の2セントを入れます。

マネージャーとして、チームメイトにYagniの原則を念頭に置いてもらう必要があります。これは、両方のチームによって提起された理由のリストを減らすのに役立ちます。

私たちの使用は主にWebのためであり、HTTP経由でサービスを公開します。場合によっては（たとえば5〜10％）、分散トランザクションが必要になる場合があります。

分散トランザクションに飛び込むのではなく、代わりに報酬の使用を検討する必要があります。

最後に考慮すべきことは、学習曲線です。プロジェクトの締め切りに応じて、マネージャーとして、新しいテクノロジーを学び始めるかどうかを決定できるはずです。

無駄にする時間が十分ある場合は、チームAとBが同じ要件に基づいて概念実証を作成する日があるような、ある種のイノベーションデーに進みます。

ちなみに、「[ WCFモデルは[DataContract]＆[DataMember]およびそれらの属性のために、POCOではありません」と言う人には、POCOは一般的にドメインエンティティであることを意味し、公開するのはベストプラクティスではないことを伝えますドメインオブジェクトをあらゆる種類のクライアントに、これがDTOの目的です。

私は今どうすればいい？この議論を建設的な方法で管理するにはどうすればよいですか？

まず、主観を遠ざけます。あなたのWebAPIチームの議論では、「Web APIは最新の方法です」 *、「WCFモデルはPOCOではありません、これらの属性のため」と「SOAPはJSONほど読みやすくて便利ではありません」とわかりました、そして決定を下す助けにはなりません。

そのため、何をすべきか：サービスで何をしたいかを決定してから、その目標と、保守性と拡張性を最小限の痛みで満たす手法を選択してください。これを行うには、使用するフレームワークで特定のアスペクトがサポートされているかどうかを単に調査するだけです。

興味深い読み物：

• Mvc 4とWcf Web API
• WCFまたはASP.NET Web API？主題に関する私の2セント
• WebAPIまたはWCF？

*：あなたはこのためにウィキペディアを参照してくださいノート、引用は次のとおりです。「Web 2.0のWebアプリケーションが移動した RESTfulなWebリソースのよりまとまりのコレクションに向けてSOAPベースのWebサービスとサービス指向アーキテクチャー（SOA）から離れて」。これは、Webページからサービスを利用する場合の使用例です。これは、WebHttpBindingを使用して、WCFでも簡単に実行できます。「これにWebAPIを使用する」とは書かれていません。

この質問が「議論を管理する方法」を超えている場合：サービスが非Webクライアントによって消費される場合、WCFを使用します。そのメタデータにより、驚くほど簡単に強く型付けされたクライアントを生成できるからです。

チーム管理は別として、どちらかを選択することはありません。各Webサービスの目的を確認し、アプリケーションの特定の部分に適切なテクノロジーを使用する必要があります。これは、チームがエンティティフレームワークを使用しているときにストアプロシージャを禁止するようなものです。

私たちの使用は主にWebのためであり、HTTP経由でサービスを公開します。場合によっては（たとえば5〜10％）、分散トランザクションが必要になる場合があります。

次に、5〜10％のWebサービスをWCFで記述します。サービスが他のプロジェクトで内部的に参照される場合、議論はありません。WCFコントラクトをインポートしてクライアントプロキシを作成できることの利点は、議論の余地がありません。統合、効率、およびタイプセーフティ全体をまったく新しいレベルに引き上げます。

Asp.net Web APIでパブリックAPI（多分）/ Ajaxリクエストに使用するものを記述します。

ページ固有のAjax呼び出しだけの場合は、Asp.Net MVCを使用できます。

選択しないで、すべてを受け入れてください。WCFとAsp.net Web APIは異なる目的を果たします。フルーツサラダにリンゴとオレンジの両方を入れることはできないと言う人はいません。いずれかを選択してすべてのシナリオを押し倒そうとするのは、まったくの怠です。

私たちのチームは数ヶ月前に同様の議論をしました。私たちの決定要因は、各テクノロジーをどのように作成して実装するかということになりました。既にMVCアプリケーションを構築しており、データバインディングにKnockout.jsを使用していたため、コントローラーがデータのAPIであるだけでMVVMを効果的に使用していました。

これにより、このプロジェクトでのテクノロジーの使用を次のように分類できました。

• Web APIは、ノックアウトおよびAjax呼び出しのAPIとして使用され、MVVMパターンのコマンドになります。Webアプリケーションのビジネスロジックは、多数のクラス、リポジトリ、およびファクトリを介してこのレイヤーの背後にラップされています。
• その後、WCFはデータストアに使用され、このWebサイトだけでなく、公開されたデータを使用した他のサイトやサービスのデータベースからデータを公開します。

これは一般的またはハイパーの技術的対応ではないかもしれませんが、最初に必要なものと、テクノロジーがどのように役立つかを判断することが、チームがどのテクノロジーをどこで使用するかを決めるのに役立ちました。

つまり、HTTPを介してサービスを公開したいが、TCPとDuplexの場合はWCFを使用する場合は、Web APIを使用した方がよいでしょう。

それが最も合理的なアプローチです。同じWebアプリケーションにWCFサービスとWebApiサービスの両方があり、両者が異なる目的を果たすことは非常に一般的です。

いくつかの引数を修正するだけです：

[DataContract]＆[DataMember]およびそれらの属性のため、WCFモデルはPOCOではありません

多くの場合、WCFモデルはdatacontract / datamember属性なしで機能します。

SOAPはJSONほど読みやすくて便利ではありません

そうではありませんが、WCF Webサービスは通常、肥大化したSOAPではなくプレーンなXMLを伝送します。これは間違いなくある読めます。

一つの引数のための WCF：WSDL利用可能である場合、メタデータのうちのプロキシを作成することができ、ほぼすべての技術のツールのトンがあります。一方、JSONスキーマはまだ広くサポートされていません。

WCF Data Servicesを活用してみませんか？優れたOData / webapiスタイルのクエリとWCFのパワーを備えた使いやすさ、そして正常に戻る機能JSON。また、次のような優れた自動wcfホスティングコードがあれば、Wcfはそれほど悪くありません。

https://github.com/ImaginaryDevelopment/MvcOdata

WebApiフロントエンドとWCF data services中間層で使用するときに、WebApi文字列を含むまたは文字列に一致するodata演算子などの単純なものをスローしたことを除いて、それらはまったく分離されていないと思います。

優れたアーキテクトは、絶対に必要になるまでテクノロジーの決定を遅らせます。

言い換えれば、クライアントが実際に接続する必要があるまで決定を下さないでください。実際にトランスポート/通信メカニズムをその上に置くことなく、完全にテストされたサービス層を構築できます。作業の95％以上は、フレームワーク外で、アダプターの「下」で実行できます。

これらのサービスをリモートクライアントに公開するときが来たら、すぐに流行のフレームワークを選択して、汎用的なサービスレイヤー上に薄いラッパーを書くことができます。

地獄、あなたの「本当の」サービス層がうまくできていれば、最小限の費用でいくつかのラッパーを試すことさえできます。

とにかくそれは独断的な答えです。 実際には、早期かつ頻繁な統合テストを容易にするために、市販の最も単純なツールを選択することもできますが、それでも依存性を制限し、実際のサービス上の単なる薄い通信層として厳密に扱います。

このアプローチをとる場合、最初に使用する最も単純なツールを選択することに気付くでしょう。チームは、必要に応じて最小限の労力でより洗練されたトレンディなツールまたはフレームワークを後で実装できることを知っているため、誰も大騒ぎしません。

したがって、私は今、同じ選択に直面しています。私たちのチームが現在使用しているWCFの機能のサブセットは何かを自問しました。異なるプロトコルを使用しますか？いいえ。トランザクションサポートを使用しますか？いいえ（ただし、カスタムの結果整合性メカニズムを使用します）。デュプレックスを使用しますか？番号。

なぜWeb APIを使用したいのですか？より簡単なフロントエンド統合（現在存在する追加のサービスレイヤーを削除）、クライアントに返信をプッシュするSignalR、GETのキャッシュ。

他の理由が見つかるかもしれません:)同様に、WCFにとどまる理由。

私があなたの立場にいたら、あなたのチームの能力を調べることから始めます。チームの全員が既にWCFを知っており、ごく一部の人しかWeb APIを知らない場合、あなたの決定はすでにあなたのためになされています。

時間があれば、知識ベースの学習と改善に投資しますが、ビジネスニーズと企業の生産性を犠牲にすることはありません。

どのような相互作用のモデルをサポートする必要があるのでしょうか？目的の外部インターフェイスはRPCまたはRESTに似ていますか？私の経験では、それは通常どこかの間ですが、ほとんどはどちらか一方です。

.Netの他のプロジェクトに独自のサービスを使用していますか？これはおそらく、あなたが尋ねることができる最も明白な質問です。WCFには、インターフェイスを別のクラスライブラリに抽象化し、クライアントをビルドおよびインジェクトでき​​るという利点があります。これの拡張として、JSONとSOAP / WSDLの両方のエンドポイントを使用してWCFベースのプロジェクトをマウントできます。また、WCFは、定義されたインターフェイスに対してより優れた保証を提供します。

ただし、一般に他のプラットフォームXMLのクライアントを使用する場合、SOAPには単純なJSONエンドポイントが持つ以上の測定可能なオーバーヘッドがあります。JSON / Web APIルートを使用する場合、エンドポイントおよびAPIと対話する方法を文書化することで、はるかに優れたものになる必要があります。

一般に、データを送信する方法と、単一のリクエストオブジェクト構造に対する応答が必要な方法を記載した簡単なAPIドキュメントを作成することをお勧めします。テストケースを最も普遍的な方法で記述し、そのように文書化します。単純なcurlステートメントをお勧めします。次に、WCFとWeb APIを使用して、いくつかのメンバーにこれを実装させます。次に、どちらが勝つかを確認します。

個人的には、いくつかの比較的大きなプロジェクトと実装をWCFで実行しましたが、実際には、JSONの結果とエラー条件を処理するためのGlobal.asax.csのオーバーライド動作を使用する実際の単純なWCFである最も単純な実装に傾いています。APIのドキュメントにcurlステートメントが含まれており、curlの例を使用してAPIのすべての機能を実行できる場合、Webインターフェースをサポートする任意の言語でクライアントを実装するのがはるかに簡単になります。これは、実際にWCFが落ち始める場所です。不可知論者向けのドキュメントを使用して明確に定義されたAPIを持つことは、外部システムを扱うときに自動化されたツールを備えた構造を持つよりも優れています。他のプラットフォームからそれらのシステムの消費者として話す。

それを超えた1つのことは、2つの異なる言語でクライアントを実装することです。C＃でクライアントを実行しますが、Node.jsまたはPythonでクライアントを実行し、実際にどの程度適合するかを確認します。この演習だけでも、APIのルーズエンドを揺るがすのに役立ちます。