7

最終的に大量の画像を含む Web アプリケーションを構築しています。これらの画像は、サイト全体でさまざまな形式で表示する必要があります。2 つのソリューションの長所と短所は次のとおりです。

  1. アップロード時に画像のさまざまなバージョンを保存する (例: Thumb、small、medium、large、verylarge)
  2. URL を使用して画像のサイズを変更します - 例: /Content/Image/1?height=300

どう思いますか？

編集: ある回答を他の回答よりも受け入れるのに非常に苦労しました。したがって、この Q/A を読んでいる人は、受け入れられた回答がコインの裏返しによって選択されたので、時間をかけて両方の回答を読んでください :) 両方とも同等です良い。

4

2 に答える 2

4

ウィキメディアを見てみると、ある種の組み合わせが採用されています。

パラメータを介してサイズを定義できます。最初のステップで、そのようなファイルが存在するかどうかを確認し、存在しない場合はその場で作成して次のリクエストのために保存します。

アップデート

あなたのコメントを読んだ後。

この質問はほぼ毎回出てきます: 速度とサイズのどちらを最適化しますか? それはあなた自身とあなたの具体的な問題のために下さなければならない決定です.

特定のサイズが x 回以上要求された場合にディスクに保存したり、y のタイムスパンの要求を取得できなかったすべての保存された画像を削除したりするなど、いくつかの追加チェックを実装できます。

于 2010-08-12T10:28:32.733 に答える
3

必然的に、パラメーターに基づいて動的サイズを提供するものはすべて、エンド ユーザーがサーバー上で合理的な (おそらく「通常よりも多く」) 量の CPU アクティビティを引き起こすことを可能にします。達成する。Oliver が提案するように、生成された画像のキャッシュは、同じ作業を 2 回行うのを避けるのに役立ち、動的ソリューションの一部であることは間違いありません。

動的サイジングの重要性を考慮する必要があると思います。すべてのケースで、定義済みのサイズ (親指、小、中、大、非常に大) を扱ってきましたが、問題なく動作しました。同じキャッシングの考慮事項が適用されますが、大量のイメージが作成される可能性ははるかに低くなります。画像がアップロードされるときにさまざまな画像サイズを作成する傾向がありましたが、まだ作成されていない場合にオンデマンドで作成するソリューションも同様にうまく機能します。

于 2010-08-12T11:53:56.253 に答える