WCFとWeb APIに関する技術的な議論をどのように管理しますか？
現在、15人程度の開発者のチームを管理していますが、テクノロジーの選択に行き詰まり、チームが2つの完全に反対のチームに分かれて、WCFとWeb APIの使用について議論しています。
Web APIの使用をサポートするチームAは、次の理由を持ち出します。
- Web APIは、サービスを記述するための最新の方法にすぎません（ Wikipedia ）
- WCFはHTTPのオーバーヘッドです。 TCP、ネットパイプ、およびその他のプロトコルのソリューションです。
- [DataContract]＆[DataMember]とそれらの属性のため、WCFモデルはPOCOではありません
- SOAPはJSONほど読みやすく、便利ではありません
- SOAPは、JSON（HTTP経由のトランスポート）と比較してネットワークのオーバーヘッドです。
- メソッドのオーバーロードなし
WCFの使用をサポートするチームBによると、
- WCFは複数のプロトコルをサポートします（構成を介して）
- WCFは分散トランザクションをサポートします
- WCFには多くの良い例と成功事例があります（Web APIはまだ若いです）。
- 双方向通信は双方向通信に最適です
この議論は続いており、私は今何をすべきかわかりません。個人的には、ツールを適切な使用場所にのみ使用する必要があると思います。つまり、HTTP経由でサービスを公開する場合はWeb APIを使用する方が適切ですが、TCPおよびDuplexに関してはWCFを使用します。
インターネットを検索しても、確実な結果は得られません。 WCFをサポートするための投稿は多数ありますが、逆に、WCFに対する不満も寄せられています。この質問の性質は議論の余地があるように聞こえるかもしれませんが、決定するにはいくつかの良いヒントが必要です。テクノロジーを偶然選択したと、後でそれを後悔するかもしれません。目を開けて選びたい。
私たちの使用法は主にWeb用であり、HTTP経由でサービスを公開します。場合によっては（たとえば5〜10％）、分散トランザクションが必要になる場合もあります。
私は今どうすればいい？この議論を建設的に管理するにはどうすればよいですか？
双方が良い議論をし、問題に関する意見が強すぎてコンセンサスを得ることができない場合、マネージャーとしてのあなたは決定を下し、議論を終わらせる必要があります。それ以外の場合は、円を描くだけで、すべての参加者の位置がさらに強化されます。長く待つほど、「敗者」側が敗北を認め、結果を生かして生産的に取り組むことが難しくなります。
すべての議論を書き留め、プロジェクトに対するそれらの重要性を評価してから、決定を下します。できない場合は、コインを投げます。あなたのプロジェクトはおそらくどちらの技術でも成功する可能性があり、不必要な議論で貴重な時間を浪費すると、不必要なお金がかかるだけです。
双方がすべての議論で100％正しいと仮定すると、どちらが重要ですか？
[DataContract]＆[DataMember]とそれらの属性のため、WCFモデルはPOCOではありません
手入れする？ POCOを必要とすることを計画していますか？
WCFは分散トランザクションをサポートします
もう一度、これはあなたが使用するものであり、他の方法をとったためにそれがない場合はビルドする必要がありますか？
基本的にどちらの中心に到達します：
- 必要なすべてを提供します（どちらも必要なすべてを提供しない場合、最小限の作業を行う必要があります）。
- 使用しないが、とにかく我慢しなければならない最低限の量のジャンクを提供します。
あなたが達成する必要のあるもののパスにないどんな出された議論も無関係であり、あなたの決定を考慮に入れるべきではありません、将来の拡張を検討するための若干の余地があります。
私の2セントを入れてください。
マネージャーとして、チームメイトに Yagniの原則 に留意するよう依頼する必要があります。これにより、両方のチームが提唱する理由のリストを減らすことができます。
私たちの使用法は主にWeb用であり、HTTP経由でサービスを公開します。場合によっては（たとえば5〜10％）、分散トランザクションが必要になる場合もあります。
分散トランザクションに飛び込むのではなく、代わりに compensation を使用することを検討してください。
考慮すべき最後のものは、学習曲線です。プロジェクトの締め切りに応じて、マネージャーとして、新しいテクノロジーの学習を開始してもよいかどうかを判断できるはずです。
無駄にする時間が十分にある場合は、ある種の イノベーションデー に行ってください。ここで、チームAとBは、同じ要件に基づいて概念の証明を作成する日を持ちます。
ちなみに、「WCFモデルはPOCOではありません。[DataContract]＆[DataMember]とそれらの属性のため、POCOではありません」と言っている人には、 POCOは一般的にドメインエンティティであることを意味し、ドメインオブジェクトをあらゆる種類のクライアントに公開することはベストプラクティスではないこと、これがDTOの目的です。
私は今どうすればいい？この議論を建設的に管理するにはどうすればよいですか？
まず、主観を遠ざけます。あなたのWebAPIチームの議論で、「Web APIは最新の方法にすぎない」*、「これらの属性のため、WCFモデルはPOCOではない」 と「SOAPはJSONほど読みやすく、便利ではありません」明らかに間違っているわけではありませんが、かなり意見が分かれており、意思決定に役立ちません。
したがって、何をすべきか：サービスで何をしたいかを決定します、その目標とその保守性と拡張性に対応する手法を選択します最小限の痛みで。これは、使用するフレームワークで特定の側面がサポートされているかどうかを調査するだけで実行できます。
興味深い読み物：
*：これについてウィキペディアを参照していることに注意してください。引用は次のとおりです： "Web 2.0 Webアプリケーションが移動した RESTful Webリソースのよりまとまったコレクションに向けたSOAPベースのWebサービスによるサービス指向アーキテクチャー（SOA）」。これは、Webページからサービスを利用する場合の使用例です。これは、WebHttpBindingを使用して、WCFでも簡単に実行できます。 「これにWebAPIを使用する」とは表示されません。
この質問が「ディスカッションの管理方法」を超えている場合：非Webクライアントがサービスを利用する場合、メタデータが驚くほど可能にするため、WCFを使用します簡単に強く型付けされたクライアントの生成。
私たちのチームは数ヶ月前に同様の議論をしました。私たちにとって決定的な要因は、各テクノロジをどのように作成して実装するかです。すでにMVCアプリケーションを構築しており、データバインディングにKnockout.jsを使用していたため、MVVMを効果的に使用しており、コントローラーは単なるデータのAPIでした。
これにより、このプロジェクトでのテクノロジーの使用を次のように分類できました。
- Web APIをノックアウトおよびAjax呼び出しのAPIとして使用し、MVVMパターンのコマンドにします。 Webアプリケーションのビジネスロジックは、いくつかのクラス、リポジトリ、およびファクトリを介して、この層の背後にラップされています。
- その後、WCFはデータストアに使用され、このWebサイトだけでなく、公開されたデータを使用する他のサイトやサービスにもデータベースからデータを公開します。
これは人気のある技術的な対応ではないかもしれませんが、最初に何が必要か、どのように、またはその技術が役立つかを判断することが、チームがどの技術をどこで使用するかを決定するのに役立ちました。
チームの管理はさておき、どちらか一方を選択することはありません。各Webサービスの目的を調べ、アプリケーションの特定の部分に適したテクノロジーを使用する必要があります。これは、チームがエンティティフレームワークを使用しているときにストアプロシージャを禁止するようなものです。
私たちの使用法は主にWeb用であり、HTTP経由でサービスを公開します。場合によっては（たとえば5〜10％）、分散トランザクションが必要になる場合もあります。
次に、これらの5〜10％のWebサービスをWCFで記述します。サービスが他のプロジェクトで内部的に参照される場合、議論はありません。 WCFコントラクトをインポートしてクライアントプロキシを作成する機能の利点については、議論の余地はありません。統合、効率、およびタイプセーフティ全体をまったく新しいレベルに引き上げます。
あなたはAsp.netウェブAPIで公開API（たぶん）/ Ajaxリクエストに使用されるものを書きます。
ページ固有のajax呼び出しの場合は、Asp.Net MVCを使用できます。
選択せず、すべてを受け入れてください。 WCFとAsp.net Web APIは異なる目的で使用されます。フルーツサラダにAppleとオレンジの両方を入れることはできないと言っている人は誰もいません。一方を他方の上から選び、それをすべてのシナリオに押し付けようとするのは、単なる怠惰です。
つまり、HTTP経由でサービスを公開する場合はWeb APIを使用する方が適切ですが、TCPおよびDuplexに関してはWCFを使用します。
それが最も合理的なアプローチです。 WCFとWebApiの両方のサービスが同じWebアプリケーションにあり、両方が異なる目的に使用されるのはよくあることです。
いくつかの引数を修正するだけです：
[DataContract]＆[DataMember]とそれらの属性のため、WCFモデルはPOCOではありません
多くの場合、WCFモデルは動作しますなし datacontract/datamember属性。
SOAPはJSONほど読みやすく、便利ではありません
そうではありませんが、WCF Webサービスは通常、肥大化したSOAPではなくプレーンXMLを伝送します。これは間違いなくis読み取り可能です。
1つの引数for WCF：使用可能なWSDLがある場合、メタデータからプロキシを作成できるほとんどすべてのテクノロジに多数のツールがあります。一方、JSONスキーマはまだすべてが広くサポートされているわけではありません。
WCF Data Servicesを利用してみませんか？素晴らしいOData/webapiスタイルのクエリと、WCFの機能を使用した使いやすさ、およびJSONを正常に返す機能。また、次のようなニース自動wcfホスティングコードがあれば、Wcfはそれほど悪くありません。
https://github.com/ImaginaryDevelopment/MvcOdata
フロントエンドでWebApiを使用し、ミドルティアでWCF data servicesを使用すると、WebApiがスローしたことを除いて、それらはそれほど離れていないと思います。文字列が含まれている、または文字列一致odata演算子のような単純なものに。
優れたアーキテクトは、決定が絶対に必要になるまでテクノロジーの決定を遅らせます。
つまり、クライアントが実際に接続する必要があるまで、決定を行わないでください。実際にトランスポート/通信メカニズムを配置することなく、完全にテストされたサービスレイヤーを構築できます。作業の95％以上は、フレームワークの外で、アダプターの「下」で行うことができます。
これらのサービスをリモートクライアントに公開するときが来たら、既製の最もトレンディなフレームワークを選び、多用途のサービスレイヤー上に薄いラッパーを書き込むことができます。
地獄、「実際の」サービスレイヤーがうまく機能している場合は、最小限の費用で複数のラッパーを試すこともできます。
それはとにかく独断的な答えです。実際には、最も単純なすぐに使えるツールで、初期の頻繁な統合テストを容易にします-ただし、依存関係を制限し、厳密にとして扱いますrealサービス上の薄い通信層。
このアプローチをとると、おそらく最初に使用する最も簡単なツールを選択し、誰も大騒ぎしないことがわかります。後で、より洗練された、または流行のツールまたはフレームワークを実装します必要に応じて、最小限の労力で。
したがって、私は今、同じ選択に直面しています。私たちのチームが現在使用しているWCFの機能のサブセットとは何かを自問しました。異なるプロトコルを使用していますか？いいえ。トランザクションサポートを使用しますか？いいえ（ただし、カスタムの結果整合メカニズムを使用します）。デュプレックスを使用しますか？番号。
なぜWeb APIを使用したいのですか？より簡単なフロントエンド統合（現在存在する追加のサービスレイヤーを削除）、クライアントへの返信をプッシュするためのSignalR、GETのキャッシュ。
多分、他の理由が見つかる可能性があります:)同様に、WCFにとどまる理由。
私はあなたがサポートする必要がある相互作用のモデルを尋ねますか？希望する外部インターフェースはRPCやRESTに似ていますか？私の経験では、それは通常どこかの間にありますが、ほとんどどちらか一方です。
.Netの他のプロジェクトのために独自のサービスを利用していますか？これはおそらく、あなたが尋ねることができる最も明白な質問の1つです。 WCFには、インターフェイスを別のクラスライブラリに抽象化し、クライアントを構築して挿入できるという利点があります。これの拡張として、JSONエンドポイントとSOAP/WSDLエンドポイントの両方を使用してWCFベースのプロジェクトをマウントできます。 WCFは、定義されたインターフェイスに対してより良い保証も提供します。
そうは言っても、一般的に他のプラットフォームのXMLからのクライアントを想定している場合は、言うまでもなく、SOAPには、単純なJSONエンドポイントの場合を超える測定可能なオーバーヘッドがあります。JSON/ Web APIルートに移動すると、エンドポイントやAPIとの対話方法を文書化することで、はるかに上手になる必要があります。
一般に、データを送信する方法、および単一の要求オブジェクト構造に対する応答をどのように要求するかを示す簡単なAPIドキュメントを書くことをお勧めします。テストケースを最も一般的な方法で記述し、そのように文書化します。簡単なcurlステートメントをお勧めします。次に、メンバーのいくつかに、WCFとWeb APIを使用してこれを実装してもらいます。次に、どちらが勝るかを確認します。
個人的には、比較的大規模なプロジェクトと実装をWCFで実行したにもかかわらず、私は実際には最も単純な実装に傾倒しています。これは、JSON結果を使用した単純なWCFであり、エラー条件を処理するためのGlobal.asax.csのいくつかのオーバーライド動作です。 APIのドキュメントにcurlステートメントが含まれていて、curlの例を使用してAPIのすべての機能を実行できる場合、クライアントがWebインターフェイスをサポートする任意の言語で実装することがはるかに容易になります。これは、WCFが実際に落ち始めるところです。不可知論的文書を備えた明確に定義されたAPIを用意することは、外部システムを処理するときに自動化ツールを備えた構造よりも優れています。他のプラットフォームからそれらのシステムの消費者として話す。
それ以上のことは、2つの異なる言語でクライアントを実装することです。 C＃でクライアントを実行するだけでなく、Node.jsまたはPythonでもクライアントを実行し、実際にどれだけ適合するかを確認します。この演習だけで、APIの不完全な部分を取り除くのに役立ちます。
私があなたの立場にあったなら、私はあなたのチームの能力を調べることから始めます。チームの全員が既にWCFを知っており、Web APIを知っているのはごく一部の場合、あなたの決定はすでにあなたのために行われています。
時間があれば、知識ベースの学習と改善に投資してください。ビジネスニーズと企業の生産性を犠牲にすることはありません。