私が現在取り組んでいるプロジェクトでは、いくつかの構造化データと、1 つまたは複数のバイナリ ファイルを受け取る WCF エンド ポイントが必要です。
サービスに対するクライアントは、これらのアップロードのサイズに制限がないことを好みますが、すべてに制限があります。
私の質問は、ファイルをアップロードするための WCF サービスが不適切なソリューションになるのはどの時点ですか?
これを何らかのコンテキストに入れると、これはエンド ユーザーがトリガーするソリューションではないため、プログレス バーなどは必須ではありません。
ありがとう、アンドリュー。
興味深い質問です、アンドリュー。
私は、世界最大級の企業で使用されている CRM ソフトウェア パッケージで WCF 開発を行っています。バイナリのアップロードとダウンロードに関して、WCF が処理できる機能に現実的な制限はないと思いますが、もちろん、クライアントの帯域幅、クライアントとサーバーのタイムアウト (デフォルトクライアントの場合は 2 分です)、サーバーの電力/ストレージ、およびその他の問題は、いくつかの創造的なアーキテクチャとプログラミングによって軽減される/軽減される可能性があります。
たとえば、一部のクライアントには、帯域幅が貧弱な第 2 世界の国々にラップトップを持つエンド ユーザーがいて、ダウンロード/アップロードのタイムアウトを引き起こす可能性があります。これを軽減した方法は、「チャンク」アップロードとダウンロードを使用することでした。つまり、500 MB のファイルをアップロードまたはダウンロードする場合、バイナリはクライアントとホストが処理できる小さなチャンク (1 MB または 10 MB) に分割されます。タイムアウトせずに接続し、ダウンロードまたはアップロードが完了するまで繰り返します。そして、これらのチャンクは、接続の「悪さ」に応じてその場で調整できます。しかし、この方法を使用して、1GB 以上のデータベース全体をクライアントのデバイスに問題なくダウンロードできました。
先史時代のPDA、iPad、Androidデバイスなどを使用しているクライアントがいますが、それらの特別な要件はすべて、巧妙なプログラミングで（再び）軽減できます.
それよりも、私は最近、WCF を使用してコンテンツを配信する婦人服カタログ アプリケーションのデモを見ました。速度は信じられないほどでした。指を弾くだけで好きなだけページを「回転」させることができ、アプリは高速のページに製品の写真と説明を問題なく入力します. その男は、これが世界で 2 番目に速いカタログ アプリケーションだと言いました。