0

MVC CMS で使用される画像キャッシュ システムを設計しています。イメージ キャッシャーの主な目的は、イメージを変更することです。拡大縮小、トリミングなどを行い、クライアント サイトにキャッシュします。

データベースと対話する画像キャッシュモデルとマッパーを作成して、画像を追跡し、それらに適用されたアクションの種類 (スケーリング、トリミングなど) を把握します。

モデルとマッパーに加えて、クライアント サイトから渡された引数に基づいてモデルと画像の作成を管理するために API で使用される ImageCacher クラスを作成しました。このクラスは画像を作成し、ビューの画像へのリンクを生成します。 .

同僚は、ロジックの大部分をモデルに入れる必要があるため、この最後のクラスの機能をモデル内に含める必要があると主張しました。

モデルの責任は、データベース レベルでキャッシュされた画像に関する情報を処理することであり、ImageCacher クラスの責任は、キャッシュする URL/画像を作成することであると私は感じているため、私は彼に丁重に同意しません (単一の責任を維持します)。原理)。これに加えて、画像の作成や表示など、プレゼンテーション関連の機能をモデルに含めるべきではないと考えています。

誰かがこれについて何か洞察を持っていますか? このタスクの分割を明確にし、画像キャッシャーを再利用可能にする特定の設計パターンはありますか? モデルにすべてのロジックを追加する必要がありますか?

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

4

1 に答える 1

0

IMO は、疑わしい結果を得るにはあまりにも多くの労力を費やしています。すべてのロジックを構築し、CPU と SQL リソースを費やして、どのクライアントにどの画像がキャッシュされているかを調べますが、クライアント側のキャッシュは信頼できない保存方法です。アプリケーションの性質はわかりませんが、複数のクライアントが同じ画像ファイル (サイズ変更、トリミングなど) を使用している場合、そもそもクライアント側に保存するのは経済的ではありません。

再。あなたの質問、IMO モデルはロジックを保存する場所です。モデル内にあると再利用しやすいからです。

于 2010-12-24T18:04:20.340 に答える