.net - チャット アプリケーションの WCF と Web Api の比較

Question

現在、チャットアプリケーションを作成しています。現在、webapi を使用してアプリケーション バックエンドを構築しています。しかし、そのためにWCFを使用すべきだったかどうかを考えています。私の目的は、クライアントが任意のテクノロジ (Microsoft スタックからである必要はありません) である可能性がある、アプリケーションを多層アプリケーションにすることです。アプリケーションの将来の拡張性の観点から心配する必要があることはありますか。

Answer 1

これが通常の Web API である場合、WebApi を正しく使用すると、非常に幅広いクライアント テクノロジを使用できるようになると言えます。ただし、非常に異なる設計上の考慮事項がいくつかあるチャット クライアントを構築しています。

チャット クライアントへのシンプルな WebApi インターフェイスを使用すると、クライアントが新しいメッセージを繰り返しポーリングする必要があるアーキテクチャになる可能性が高く、理想的ではない可能性があります。あなたが見つけるほとんどの.NETチャットの例は、通常、ソケットなどを介してTCPレベルで動作します。たとえば、これらの3つの例とクライアントは、HTTPを介してメッセージを「リッスン」できますが、それほど単純ではありません。

チャット API に適したプッシュ (またはシミュレートされたプッシュ) をサポートする WebApiの例があります。あなたにとって問題かもしれません。

したがって、WCF を使用して TCP およびソケット レベルで作業するのが最善の方法かもしれませんが、ソリューションに Web ベースの Api が本当に必要で、プッシュ (タイプ) メッセージングが必要な場合は、SignalR または CometD の実装を参照してください。プッシュをサポートせずに、多くのクライアント テクノロジで利用できるオープンな Web Api が必要な場合は、WebApi が最適です。

余談ですが、クライアント (既存のチャット クライアントなど) に対して最も幅広いサポートを得るには、XMPP のような標準化されたチャット プロトコルの使用を検討してください。これは、必要に応じて SignalR で使用できます。

Answer 2

私の見解では、クライアントが任意のテクノロジ（MSであるかどうかに関係なく）および任意のタイプ（Web、モバイル、デスクトップ、スマート、リッチなど）である可能性がある場合は、MVCWebApiを使用する必要があります。それははるかに相互運用可能でとても楽しいです！このソリューションはフロントエンドサービスに適していることに注意してください。バックエンドサービスは、WCFなどの別のテクノロジーである可能性があります。