4

asp .net MVC で記述された JavaScript ベースのデータ駆動型アプリケーションで Signalr を通信方法として使用することの利点と欠点は何ですか?

ありがとうございました、

4

1 に答える 1

6

もちろん、SignalR が提供するもの、つまり JavaScript クライアントに焦点を当てた単純な二重 Web サービス レイヤーが必要でない限り、SignalR を使用しないでください。ASP.NET を初めて使用する場合は、おそらくすぐに必要になるものではありません。複雑なデータ駆動型の JavaScript アプリケーションを作成する前に、他にも学ぶべきことがたくさんあります。 . また、.NET クライアントのみを使用する場合は、WCF を使用してください。WCF の方が柔軟性が高く、その静的型付けは C# および VB.NET により適しています。

とはいえ、JavaScript アプリケーション用に .NET ベースの Web サービス バックエンドが必要な場合は、SignalR が非常に適しています。Windows Communication Foundation よりも構成が簡単で、JavaScript アプリの場合ははるかに優れた機能セットを備えています。Microsoft が後援しているようで (彼らは Microsoft.AspNet 名前空間に置くことを許可しています)、それを担当する人々は賢く、非常に勤勉であるようです (時々少し辛辣ではありますが)。真夜中にバグを報告したことがあり、15 分以内に応答があり、朝起きるまでに修正がありました。もちろん、それはオープンソースであり、プルリクエストを検討する意思があるため、修正が必要な場合は、Microsoft の以前のクローズドソース モデルよりもうまくいくでしょう.

唯一の本当の欠点は、かなり新しいことです - 最近 1.0 RC1 ステータスに達しました - そのため、あると便利ないくつかの機能が欠けており、まだいくつかのバグがあります (もちろん、これらは最終的に修正される予定です)。

まだ少し新しい例を次に示します。複雑なオブジェクト グラフをシリアル化しようとする場合にほぼ確実に遭遇する問題の 1 つは、オブジェクト参照に Json.NET 独自の形式を使用しているため、次のような大量の JSON が生成されることです。

{
  "$id": "57",
  "Name": "_default",
  "User": {
      "$id": "58",
      "UserTag": "ken",
      "Sessions": [{
          "$id": "59",
          "SessionId": "0ca7474e-273c-4eb2-a0c1-1eba2f1a711c",
          "User": {
              "$ref": "58"
          },
          "Room": {
              "$ref": "57"
          }
      }],
  },

  "Sessions": [{
      "$ref": "59"
  }]
}

Session[]配列を読み取って、その中の唯一のオブジェクトがまったくではなくSession、単一の$refプロパティを持つ任意のオブジェクトであることを発見することは、あまり役に立ちません。これを回避するには、すべての SignalR 呼び出しをJsonNetDecycleなどでラップする必要があります。難しいことではありませんが、SignalR 自体で処理できれば便利です。(そしてもちろん、もし私がもっと上手だったら、自分でコードを作成してプル リクエストとして送信しますが、まだそれに慣れていません。)

于 2012-12-31T19:38:42.890 に答える