問題タブ [loadoptions]

2つのテーブルがあるとしましょう。

• 報告する
• コメント

そして、私がデータベースコンテキストを持っていると仮定します：

各レポートのすべてのコメントもロードされていることを確認するにはどうすればよいですか？

この時点で、データベースから切断したいのですが、コメントにはアクセスできます。（例えば：）

私はここで議論されている方法について知っています：

需要の高いASP.NETWebサイトのLinqtoSqlでコンパイルされたクエリに関する一般的な問題を解決する

...しかし、これは私の状況では機能しません：

「クエリから結果が返された後は、ロードオプションを設定できません。」

Codesmith PLINQOスクリプトを使用してエンティティとマネージャーコードを生成していますが、マネージャーコードは次のようになります。

最初に、静的DataLoadOptionsを次のようにSearchmanagerクラスにドロップしてみました。

...次に、次のようにGetAllメソッドのコンテキストに提供します。

...そしてそれは私が上で述べたエラーを私に与えました。これは、クエリがすでにコンパイルされているため、「余分な」DataLoadOptionsを追加できないためですか？もしそうなら、クエリがコンパイルされる前に、どのようにDataLoadOptionsを適用することが可能でしょうか？

次の DataLoadOptions を使用しています。

Family オブジェクトは FamilyLanguages のリストを返しますが、FamilyLanguages は LanguageID しか取得しておらず、Language オブジェクトは null です。

これは Visual Studio 2010 Beta 2 で動作していましたが、現在は Visual Studio 2010 Release Candidate を使用しています。これはもはやこれを行う適切な方法ではありませんか? LINQ に変更はありますか?

私の.NETMVCプロジェクトは複数のユーザーでテストの段階に達しており、Linq2Sql DataReaderの問題に関連して（サイト内の任意の画面から）一見ランダムなエラーが発生しています
。および
'ExecuteReaderには、開いていて利用可能な接続が必要です。接続の現在の状態は閉じられています。
これらのエラーは、リンクがダブルクリックされた場合、ブラウザの複数のタブ、または異なるブラウザが同時に更新された場合のシングルユーザーテスト中にも頻繁に表示されません。

これらの問題がDataContextのスレッド化の問題にあるのではないかと思います。

現在、私はビジネスプロセスごとに個別のリポジトリを使用するリポジトリアプローチを使用しています。各リポジトリクラスは、そのコンストラクタでDataContextインスタンスを起動し、これはリポジトリ内のほとんどのメソッドで使用されます。
ただし、一部のメソッドはDataLoadOptionsを更新して、ビューデータの積極的な読み込みを強制するため、これらのメソッドはDataContextの独自のインスタンスを作成します。
また、一部の画面には複数のビジネスオブジェクトからの情報が表示されるため、1つのリクエストに2つまたは3つのリポジトリが含まれる場合があります。その結果、リクエストごとに多数の個別のDataContextインスタンスが作成される可能性があります。
必要に応じてDataLoadOptionsを使用し、クエリ結果にToList（）を適用して、すべてが事前に読み込まれるようにする（ビューがレンダリングされるまで待機しない）ようにすることで、積極的な読み込みアプローチを適用しようとしました。したがって、各DataContextはかなり短い期間。

エラーは同じDataContextを再利用する複数のスレッドに関連しているように見えるので、Rick Strahlのスレッド固有のDataContextFactory（http://www.west-wind.com ）に沿って、リクエストごとに1つのDataContextを実装することを考えています。 /weblog/posts/246222.aspx ）またはSteve Sandersonの例（ http://blog.stevensanderson.com/2007/11/29/linq-to-sql-the-multi）のような単純な「作業単位データストア」アプローチ-tier-story /）。

しかし、解決すべきDataLoadOptionsの問題があります。追加のスレッド固有のDataContextを作成することもできますが、それは、リクエストごとに1つのDataContextを使用するという私の目標からは外れているようです。したがって、同じDataContextを再利用するが、Kevin Watkinの例（ http://www.mrkwatkins.co.uk/Blog/2010/05/）のように一部のメソッドのLoadOptionsを一時的に変更するか
、標準のDataLoadOptionsアプローチを廃止することを検討しています。 Visual Studioマガジン（http://visualstudiomagazine.com/Articles/2007/11/01/Optimize-LINQ-to-SQL-Performance.aspx？ページ=3）

だから私の質問は、誰かが同様のランダムなDataReaderの問題を経験したことがありますか、どのようにそれらを解決しましたか、そして私がリンクしたそれらのソリューションを実装することによって問題を解決する可能性がありますか？

いつものように時間は厳しいので、問題が実際にどこか別の場所にある場合は、ソリューションの実装に費やしたくありません。どんな助けでも大歓迎です！

PS。これは非常に高レベルの質問であり、問​​題が実際にどこにあるのかわからないため、特定のコード例は含めていません。

LoadOptionsLinqToSql でプロパティを設定するときDataContextに、コンテキストが別のクエリから既に結果を返している場合、「クエリから結果が返された後、読み込みオプションを設定することはできません」という例外がスローされます。

私が知りたいのは、DataContext オブジェクトを調べて、以前のクエリの結果が既に返されているかどうかを確認する方法はありますか?

CompiledQueryのパフォーマンスを調査していますが、CompiledQueryはLoadWithにアレルギーがあります。

このコードは、左結合SQLクエリを発行することによってロードされた各CustomerインスタンスのOrdersプロパティにデータを入力します。LoadWithなしでクエリを書き直して同じ結果を得るにはどうすればよいですか（顧客はOrdersプロパティにデータを入力しています）？

次のように呼び出して、データ テーブルを更新DataTable.LoadDatatRowしています。

さて、これは読みやすくするために少し簡略化されており、LoadDataRow行は少し長い (およそ 9 つの配列値) ですが、大きな関数呼び出しなどは含まれておらず、書式設定された文字列といくつかの?ケースだけです。このコードは、テーブルに約 50 個の値があり、約 10 Hz のリフレッシュが得られる場合に正常に機能します。しかし、通常よりも多くの値 (たとえば 200) を取得すると、指数関数的に上昇し、約 0.2 Hz になります。これは遅すぎる。

列挙可能な大きな測定値があるときに指数関数的に減速する理由を誰かが知っていますか? それは何か関係がありますかOverWriteChanges（他の理由で必要だと確信しています）。または、 内でオブジェクトを作成している可能性LoadDataRowがありますか、それとも他の理由がありますか?

私は別のもので遊んLoadOptionsだことがありますが、それは問題ではないようです。処理時間がこれほど大幅に増加している理由を説明できず、それを修正する方法もわかりません。