デスクトップアプリケーションにSignalRを使用するのは正しいですか？
SignalRはWindowsデスクトップアプリケーション（winforms/wpf）に適していますか？
WindowsデスクトップアプリケーションでSignalRを使用する利点と欠点は何ですか？
パフォーマンスに関する考慮事項はありますか？
サーバーと多くのクライアント間でリアルタイム接続を確立したい。接続は一定です。
SignalRはWindowsデスクトップアプリケーション（winforms/wpf）に適していますか？
signalr.net からの答えは：
SignalRを使用して、ASP.NETアプリケーションにあらゆる種類の「リアルタイム」Web機能を追加できます。
（他の人が正しく述べているように、それは自己ホストできるので IISの必要なし ）
したがって、答えはnoのようです。これはサーバー側のAPIです。しかし、SignalRをダウンロードすると、サーバー側のAPIだけでなく、Microsoft.AspNet.SignalR.Client45アプリケーションで使用します。 WPF、WF、さらにはコンソールアプリケーションでも機能します。
たとえそうでなかったとしても、SignalRは WebSockets protocol の単なるラッパーであり、これは事実上すべてのプラットフォームで使用できるHTTPプロトコルの一部です。ダウンロードには、たとえばiOSやXamarinのサンプルも含まれています。
WindowsデスクトップアプリケーションでSignalRを使用する利点と欠点は何ですか？
サーバーとの間でリアルタイムの通知を行うため。
パフォーマンスの問題はありますか？
基準点がないため、これは答えるのが難しい質問です。パフォーマンスの良し悪しと比較して？一般的に言えば、それについてあまり心配する必要はないと思います。 API自体は高速であり、他に必要な遅いpull要求を防ぐことができます。
HTMLを含むクライアントアプリケーション、WPF、Windows Phone、UWP、iOS、AndroidでSinglarRハブを使用することは絶対に正しいことです。 Microsoftは、多くのプラットフォームでクライアントライブラリを作成しています。
SignalRのホスティングに関しては、WPFアプリケーションでSingalRサーバー（ハブ）を明確にホストできますが、理由が必要です。
理由は次のとおりです。
- IISは利用できません
- APPがどこで使用されるかは事前にわかりません。他のアプリに通知するアプリを実行するだけです
- パフォーマンス-IISはパフォーマンスのオーバーヘッドを追加します。
ちなみに、SignalRとOWINは新しいASP.NET 5のインスピレーションとなっています。ASP.NETアプリをWPF、コンソールアプリケーション、IISなしのWindowsサービスアプリ、さらにはLinuxでホストできるようになりました。
http://www.asp.net/signalr/overview/deployment/tutorial-signalr-self-Host
サーバーと多くのクライアントを使用したセットアップ：サーバーから一部のクライアントに「プッシュ」通知が必要な場合は、SignalRを使用すると便利です。
私はWPFクライアントでそうします。
シグナル機能を使用してWebサイトを構築する場合、サイトがホストされるsignalRサーバーと、サイトを参照するWebブラウザーで実行されるjavascriptクライアントがあります。
記憶にない年から、Webブラウザは（そして今でも）...まあ、...デスクトップアプリケーション...
したがって、SignalRを使用してWebサイト（Webサーバー）に接続するデスクトップアプリケーション（Webブラウザー）があります。
そのため、デスクトップアプリケーションにsignalRを使用するのが正しいだけでなく、これが目的です。率直に言って、ユーザーがデスクトップ（またはスマートデバイス）の前に座っており、 「クラウド」には存在しません（マトリックスのNeoでない限り）。 signalRを使用すると、デスクトップ環境（Webブラウザーまたは別のデスクトップアプリケーション、たとえば、自宅の照明を制御したり、プリンターで何かを印刷したアプリケーション）に表示されるサーバーからの「リアルタイム」反応があります。