2009-03-13 3 views
12

Lubię pobierać dane z niecierpliwością przy użyciu Linq2SQL. Kod jest podobny do:Linq2SQl chciwe obciążenie z wieloma DataLoadOptions

 DataLoadOptions options = new DataLoadOptions(); 

     options.LoadWith<Product>(c => c.ProductCompanies); 

     options.LoadWith<Product>(c => c.OrderDetails); 

     db.LoadOptions = options; 

     IEnumerable<Product> products = db.Products.ToList<Product>(); 

Sprawdzam, czy wygenerowałem więcej niż jedno zapytanie SQL zgodnie z oczekiwaniami. W rzeczywistości tylko ładnie ładuje się z Product i OrderDetails, a ProductCompany jest zapytany jeden po drugim. Czy zrobiłem coś złego tutaj? Lub jest to problem Linq2SQL? Czy mamy jakieś obejście?

Wielkie dzięki!

Aktualizacja: Sprawdzam sql z SQL Profiler. Stwierdziłem, że zarówno Leppie, jak i Ian są poprawni. Są ograniczone w jednej transakcji. Ale kiedy ustawiłem to jako leniwe obciążenie, otworzyło ono wiele połączeń.

+1

uważać , DataLoadOptions tworzy bardzo nieefektywne zapytania. –

+0

Dzięki, Chad! W następnym projekcie wrócę do Nhibernate: =) –

Odpowiedz

3

Nie, nie zrobiłeś nic złego, Linq2SQL pakuje wszystko w jedną transakcję, ale może wykonać nieograniczoną liczbę zapytań dla wymaganego wyniku. DataLoadOptions jest zwykle używany tylko wtedy, gdy DataContext nie jest dostępny dla całego kontekstu wynikowego użycia. Jeśli możesz zachować wartość DataContext podczas wykonywania, najlepiej jest polegać na odroczonym wykonaniu (domyślnie).

+0

Dzięki, leppie! Sprawdzam profil SQL, sqls są w jednej transakcji. –

2

Zgodnie z docs:

Podczas kwerendy dla obiektu, faktycznie odzyskać tylko obiekt, który wnioskowano. Powiązane obiekty nie są pobierane automatycznie w tym samym czasie.

Klasa DataLoadOptions udostępnia dwie metody uzyskania natychmiastowego załadowania określonych powiązanych danych. Metoda LoadWith umożliwia natychmiastowe załadowanie danych związanych z głównym celem. Metoda AssociateWith umożliwia filtrowanie powiązanych obiektów.

Posiadanie wielu instrukcji SQL nie zaskakuje mnie. Myślę, że różnica polega na tym, że wszystkie instrukcje są ładowane z góry, zamiast leniwie ładować je na żądanie.

+0

Dzięki, Ian! Myślę, że masz rację. –

+2

Zaskakujące jest to, że 'LoadWith ' * nie * gwarantuje szybkie ładowanie: -/ –

16

Ten problem również pojawił się w pewnym kodzie, a po wielu eksperymentach i googlowaniu wygląda na to, że LINQ może łączyć się tylko w jednej relacji jeden-do-wielu z każdej tabeli: jeśli spróbujesz podać więcej niż jeden do wstępnej załadować go po prostu (przypadkowo?) wybiera, który z nich pre-load i których inni opuścić odroczone (po prostu ignorując te podpowiedzi LoadWith)

inni ludzie napisali to też na przykład

http://codebetter.com/blogs/david.hayden/archive/2007/08/06/linq-to-sql-query-tuning-appears-to-break-down-in-more-advanced-scenarios.aspx

+2

Nice link. I jeszcze lepiej, ta odpowiedź właściwie odpowiada na pytanie - * "DLACZEGO DOKUMENTACJA NIEPRAWIDŁOWA I/LUB MIESZAJĄCA" *? 'LoadWith ' może bardzo łatwo * po cichu zawieść * lub * zrobić własne * i powodować problemy podczas uzyskiwania dostępu do elementów poza okresem życia DataContext. Nie dbam nawet o efektywność - po prostu chcę pracować nad semantyką. Jedynym niezawodnym sposobem, jaki znalazłem, aby skutecznie sobie z tym poradzić, jest ręczne * wymuszanie * dostępu w zakresie DataContext. –

Powiązane problemy