3

Linq-to-SQL を使用して、データをプリフェッチしたいと思います。

1) 一般的な解決策はDataLoadOptionsを処理することですが、私のアーキテクチャでは次の理由で機能しません。

  • オプションは最初のクエリの前に設定する必要があります
  • IOC を使用しているため、DataContext を直接インスタンス化していません (インスタンス化時にコードを実行することはできません)。
  • 私の DataContext は、Web リクエストの間永続的です

2）データとその子をメソッドにロードし、データのみを返すことに基づく別の可能性を見てきました（したがって、子はすでにロードされています）ここで例を参照してください

それにもかかわらず、私のアーキテクチャでは、それは機能しません:

  • クエリはリポジトリからカスケードされ、句を追加する多くのサービスで使用できます
  • 私はインターフェイスを操作します.linq-to-sqlオブジェクトの具体的なインスタンスはリポジトリを離れません(はい、インターフェイスを操作して句を追加できます)
  • 私のリポジトリは一般的です

はい、このアーキテクチャはかなり複雑ですが、レゴのようにコードをいじることができるのでとてもクールです ;)

私の質問は:データをプリフェッチする他の可能性は何ですか?

4

3 に答える 3

1

私のアプリでは、おそらくあなたの潜在的な解決策＃2のバリエーションを使用します。説明するのは少し難しいですが、簡単に説明します。カスタムレイジークラスを使用してモデルのレイジー読み込みをチェーンおよび延期し、で利用するLinqToSql固有の差分実行から抽象化しIQueryableます。利点：

  • ドメインモデルとサービスレイヤーの上位は、必ずしもLinqToSqlプロバイダーに依存する必要はありません（必要に応じて、DALをインターフェイスと交換できます）
  • 私のServiceメソッドは、特定の遅延読み込みの実装を抽象化するクラスを使用して、遅延読み込みの複数の「アンカーポイント」を含む完全なオブジェクトグラフを返すことができます。そのため、LinqToSql固有のDiffered Executionなどを使用できます（例：anonデリゲート。この回答を参照してください）
  • アプリ全体で（必要に応じてUIまで）結果を維持できるためIQueryable、パフォーマンスを気にすることなく、無限のLINQクエリチェーンを使用できます。
于 2009-11-08T07:02:10.637 に答える
1

私は他の可能性を認識していません.LinqToSqlを限界まで押し上げたようです(ただし、私は間違っているかもしれません)。

この時点での最良の選択肢は次のとおりだと思います。

  1. いくつかの「非ジェネリック」メソッドをアプリケーションに追加して、熱心な読み込みが必要な特定のシナリオのみを処理し、それらのメソッドに「通常の」「ジェネリック」インフラストラクチャを使用しないようにします。
  2. 熱心な読み込みと遅延読み込みをより洗練された方法でサポートする ORM を使用してください。
于 2009-10-24T11:41:35.900 に答える
0

解決策を見つけました。私の答えは「依存性注入」です。

これは通常、IOC に同梱されており、インスタンス化時に IOC コンテナーでクラスの注入を管理できることを意味します。

必要なのは、DC をインスタンス化するときにCustomDCParameterクラスを挿入することだけです。そのクラスにはルールが含まれ、コンストラクターはそれらすべてを適用します。

于 2009-10-26T10:12:10.683 に答える