2

AzureにWCFサービスを展開しています。Windows Phone 7で実行されるこのサービスを使用しているクライアントがあります。すべて正常に機能しましたが、アイテムが失われた大きなファイルや列挙型ファイルをサーバーに送信しようとすると、エラーが発生しました。構成ファイルには、最大メッセージサイズ、最大配列長などを構成できることがわかりました。だから私はデフォルト値にいくつかのゼロを追加し、それは機能しました。しかし、私はこの解決策に満足していません。それは汚れているからです。

私の質問は：

1.メッセージサイズの制限を無意識に増やすことの不利な点は正確には何ですか？それはサービスにどのように影響しますか？

2.メッセージサイズを増やす代わりに、私にとって代替手段は何ですか？

特に、同じメタデータと膨大な量のロケーションポイントで構成されるGPSトラックをサーバーに送信する必要がありました。

概念を正しく理解していれば、デフォルトでwcfはXMLベースのSOAPを使用します。したがって、送信されるオブジェクトはXMLとしてエンコードされます（.netでのXMLシリアル化と同様ですか？）。では、BLOBを送信したり、ストリームを介して大きなオブジェクトをアップロードしたりするために、何らかの方法でバイナリモードに切り替えることができますか？または、WCFサービスを完全にバイパスして、APIを公開するサーバーストレージ（SQLazureやAzureBlob Serviceなど）に直接アップロードするという私の愚かなオプションはありますか？

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

4

3 に答える 3

2

ペレッツがコメントで述べたように、それが起こるはずです。

デフォルトはまさにそれです-デフォルト。「推奨」設定でも、疑似最大サイズでもありません。それらはあなたのニーズに基づいて変更することができます（そしてそうあるべきです）。

（まだ使用していない場合は）net.tcpバインディングを使用して、（シリアル化に関して）データを少し適切に処理できますが、実行していることは、WCFとその機能の範囲内です。

于 2012-04-23T00:11:10.697 に答える
0

これらの設定の最後に0を付けることによって、メッセージサイズを任意に増やすべきではありません。はい、これらは変更可能なデフォルトですが、制限に達したときにメッセージサイズを増やすことは、常に頼るべきものではありません。サイズがこのように小さい理由の1つはセキュリティです。これにより、クライアントがサーバーに巨大なメッセージを殺到してダウンさせるのを防ぐことができます。また、スケーラビリティに役立つ小さなメッセージをクライアントが送信することを奨励します。

使用できるエンコーディングがあります。使用するバインディングによって異なります。とにかく、WCFはSOAPをバイナリとしてエンコードすると思いました...しかし、私は間違っているかもしれません。私は6か月間WCFに触れていません。

以前のプロジェクトでは、サイズ制限に達するたびに、データをより小さなチャンクに分割することを検討しました。私たちがこれまでに行った中で最高のことの1つは、一度にサーバーから10〜20程度のレコードしか取得しないGUIにページング可能なグリッドを実装することでした。Entity Frameworkは、すべてのグリッドに対してこれを行うための単一の汎用スキップテイククエリを記述できるという点で優れていました。

サイズを大きくするだけで簡単に修正できます...それ以上大きくすることができなくなるまで。そのもろくて壊れたアプローチ。

于 2012-04-23T04:51:55.927 に答える
0

私は巨大なGPSトラックでまったく同じ問題を抱えていました。私は本当にこの種の仕事に石鹸を使わないことを提案します。WebHttpBindingを使用してストレージからストリーミングを実装するか、ASP.NET WebAPI（MVC4に付属し、IISの外部でホストできます）などを使用して、クライアントへのストリームの低レベルの配管を行うことができます。これにより、複数のダウンロードストリームと、この種のタスクで必要になる可能性のあるすべてのものを実装できます。

このようなシステムの全体的な設計コンセプトと同様に、1つのツールで問題を解決できると考えないようにしてください。ちょうどタスクのために取った権利を使用してください。いくつかのビジネスタスクがある場合-それらのためにトランザクションws-*ベースのサービスを実装します。大量のデータを転送するには、RESTサービスのようなものを使用します。これは、トラックのクエリにも役立ちます。

例：Tracks / {deviceid}/{trackDate}。{format}。

お気軽にお問い合わせください=）

于 2012-04-23T20:57:32.200 に答える