0

私はデータレイヤーとサービスレイヤーを曖昧にして、Rob Conery's Storefrontモデルに基づいています。ロブズのように、私のドメインオブジェクトの多くはLazyList<>LazyItem<>とチェーンされ、Linq2Sqlが提供する遅延実行を利用します。 Lazy*タイプはthis awesome delegate approachではなくIQueryable<T>を使用します。サムネイル画像を怠惰に生成する方法は?

latest3Activities[0].Gallery.Images.Inner[1].FullImage 

GalleryタイプはLazyList<PhotoGalleryImage>のImagesプロパティを持っており、:

だから私はこのようなオブジェクトグラフを持っている(基本的には、それぞれの活動は、多くのimages-サムネイルとフルサイズの写真のフォトギャラリーを持っている必要があります)そのLazyListのIList<PhotoGalleryImage>は、あなたが見るInnerです。各PhotoGalleryImageアイテムはFullImageプロパティとThumbnailプロパティ(両方ともImage)を持ちます。

考えられるのは、完全にアップロードされた写真がPhotoGalleryImage.FullImageプロパティに保存され、最初はThumbnailプロパティがNullです。 私はこの後です:初めてThumbnailプロパティにアクセスしたときは、Nullです。私のサービス層でThumbを生成し、DBに保持してから、小さな写真であるImageインスタンスを返します。私はフルサイズの画像からサムネイルを作成するためのコードをすべて持っているので、ここでは問題はありません。私が把握カント何

は(私のIQueryable<>アーキテクチャの文脈で)Thumbnailプロパティの最初のアクセスをキャッチして、サービス層を持っている方法ですサイズ変更はなくリポジトリ(DAL)を行います。私は、サービス(ビジネス)層がこの機能の決定に責任を負うべきだと強く思っていますが、私はそれを動作させる方法がわかりません。

現在、私は、リポジトリ内の私のドメインクラスからLinq2Sqlクラスへのマッピングは、私が参照しているこの '最初のアクセス'を識別するのには良い場所だと思っていますが、サービス層に入れて縮小を実行してください(または可能であれば、)。

私のデザインは、私がレポに変換をさせることを制限するかもしれません。たぶん、私はサービス層がこのロジックを実行することを望んではいけません。たぶん私のデザインはちょっと恐ろしいので、私は本当にこの混乱に直面してはいけません。

Pls help。すべてのフィードバックは高く評価されます。

+0

サムネイルされたImageインスタンスをどのように使用するかを具体的に説明してください。 –

+0

ok-アクティビティの詳細ビューでは、関連するフォトギャラリーの親指で、ajax(Facebookがどのように動作するか)を介してロードします。各ギャラリー画像アイテムは、サムネイル(画像のテーブルの場合)とフルサイズのサムネイル(ユーザーがサムをクリックした場合)の両方にアクセスできるようにします。 –

答えて

2

遅延初期化のポイントは、いつリソースが必要かわからないため、リソースの割り当てを遅らせることです。

あなたの場合、これは実際には意味がありません。イメージがアップロードされるとすぐに、サーバーはサムネイルを必要とします - ユーザーは新しいイメージをすぐに見たいのですか?したがって、サムネイルの作成を延期することは、ROIにプラスの効果をもたらしません。

+0

合意。これは私が後にした概念的な答えのタイプです。 –

+1

確かに - これは欠点だが、これは個人用サイトスターターキットが正しいと思うものの1つです - 画像やさまざまなサムネイルをデータベースに保存する場合は、サムネイルをアップロードして生成する/最初に保存する。 –

0

イメージを表示するには、イメージURIが必要であるとします。イメージURIはIThumbnailingServiceで渡すことができ、必要に応じてサムネイルを生成し、生成されたイメージを指す有効なURIを返します。

+0

詳細をご覧ください。私はURIが私に何か良いことをする方法を理解していない。 Thumbnailプロパティから返されたImageインスタンスが必要になります。 Thumbnailプロパティを呼び出してDBからImageを取得してThumbnailプロパティを呼び出し、 'lazy-gen'キックを実行するという唯一の違いは、gennedされている間に数百ミリ秒間ブロックされることです1回目。 –

2

アップロードされた画像、サムネイルの生成、サムネイル画像を生成するコードがどこにあるのかという問題については、2,3ヶ月前に非常によく似た問題がありました。私はあまりにも本当にこのコードがサービス層に属していると感じていました(イメージファイルとサムネイルの記憶域がインターフェイスに抽象化され、IOCコンテナ経由で注入されていて、自分のドメインに依存性注入をしたくないからです層)。

最後に、UIコントローラからのサービスレイヤへの呼び出しによって、画像がアップロードされた時点ですべてのサムネイルが作成されました。私はこの前にドメイン層の画像を生成しようとしました。これを行うには、ドメインレイヤーがイメージを生成する必要があるときに、サービスレイヤーに接続されたイベントを発生させるパターンを使用しました。サービスレイヤーは、ストレージシステムのインスタンスをイベント引数を介してドメインレイヤーに渡して、ドメインレイヤーがイメージを保持できるようにしました。これは、サービス層のロジックを活用する方法として、ドメインモデルでイベントを使用することについて私が遭遇したUdi Dahan's blogに関するいくつかのアイデアに非常にゆるやかに基づいていました。私はUdiのサイトのリファレンスが残念ながら見つからないが、どこかにある。いずれにしても、それは本当に正しいとは感じませんでした。別のルート経由でタイトなカップリングのように思えました。そのため、サービスレイヤを介して画像が最初にアップロードされた時点でサムネイルを作成することに戻りました。しかし、おそらくあなたの場合、ドメイン層からのイベントのアイデアを使ってサービス層のロジックを呼び出すことができます。アイデアそのものには価値があり、私がやっていることにはあまり合わないと確信しています。

+0

おかしい。私は2つのレイヤーを「プランB」と呼ぶイベントを考えましたが、「それは本当に正しく感じられませんでした」と感じています。それはあまりにも混乱のようにも見える。私はこれらの画像が初めてアップロードされたときは、アップローダがアップロードから成功した投稿を取得することになると思います。つまり、作成時に親指を作成するのか、怠惰なのかは関係ありません。 –

関連する問題