Entity framework – obowiązkowa minimalna konfiguracja #dajsiepoznac

Lazy loading

Kiedy korzystamy z EF należy pamiętać o tym, aby zawsze wyłączyć leniwe ładowanie (lazy loading) w przeciwnym wypadku za każdym razem gdy będziemy sięgać po dane które leżą w innej tabeli niż ta, która została początkowo zaciągnięta z bazy danych EF zrobi to za nas. Brzmi fajnie, ale gdy pomyślicie że taka operacja może wykonać się w pętli, pomysł szybko przestaje być tak miły. N wykonań pętli N pojedynczych zapytań do bazy danych. Minusem wyłączenia lenia w EF jest to, że jeśli nie powiemy wcześniej EF że chcemy wykonać operację JOIN nie będziemy mieli dostępu do danych z innej tabeli.

Kod wygląda tak, pierwsze zapytanie bez, drugie z instrukcją JOIN

Linia (@22) wyłącza lazy loading. Linia (@12) wyciąga z bazy tylko osoby, jesli pole Properties będzie nullem. Linia (@13) wyciąga z bazy osoby oraz wykonuje operację JOIN, lista cech w osobie zostanie wypełniona pasującymi wartościami. Ostrzeżenie: ponieważ w przykładzie wywołanie jest jedno pod drugim, gdy postawi się breakpoint po obu (@14), referencja osoby zostanie zaktualizowana. Może się więc okazać, że w przypadku p1 oraz p2 pola properties będą już ustawione. Zalecam w przypadku samodzielnego sprawdzania przykładu, postawić breakpoint odpowiednio w liniach @12 oraz @13 i podejrzenie wartości property.

Logowanie

Często pojawia sie problem logowania zapytań które generuje EF, zawsze szukałem, paczek, rozwiązań czy gotowych bibliotek. Aż pewnego pięknego razu na SO znalazłem odpowiedź, która wygląda tak jak w linii 21. Najprościej jak się da, dopinam się do wewnętrznego logera oraz wypisuje na Debug.Trace informacje o zapytaniach, wyglądają one tak:

Widać tam wywołania dwóch zapytań (@12i @13) prosty oraz ten z JOIN, widoczny jest czas potrzeby na wykonywanie operacji jak i informacje o rozpoczęciu i zakończeniu połączenia. Wszystko co potrzeba aby sprawdzić czy zapytanie zostało wygenerowane w akceptowalny przez nas sposób – me gusta!

7 thoughts on “Entity framework – obowiązkowa minimalna konfiguracja #dajsiepoznac

    1. Także nie mogę się zgodzić z tym, że zawsze należy wyłączać lazy loading.
      Owszem, w większości przypadku jest to prostsze niż późniejsze usuwanie nieoptymalnych zapytań lub problemów N+1. Jednak prawidłowo użyty, ten mechanizm jest użyteczny. Tylko wymagający uwagi.

        1. Wówczas, gdy nie wiadomo, które dane będą potrzebne podczas wykonywania kodu. Jeśli logika biznesowa w zależności od jakichś warunków raz będzie się odwoływała do jakiegoś podobiektu, a raz nie. W takiej sytuacji nie ma sensu ładować danych na zapas.

          Ale to nie jest raczej decyzja do podjęcia a priori, trzeba ją poprzedzić testami wydajnościowymi i profilowaniem.

  1. Pingback: dotnetomaniak.pl
  2. Witam,

    również nie zgodzę się ze stwierdzeniem, że to obowiązkowa konfiguracja. Użyłem EF w kilku dużych projektach i jeszcze nigdy tego nie zrobiłem. Oczywiście wymaga to obeznania w sposobie działania Frameworka.

    Np. gdy tworzymy listę osób, nie ładujemy całej osoby, tylko tworzymy specjalną Encję – PersonListItem, która posiada tylko te atrybuty potrzebne do tego celu. Używając Select() i Include() wygenerowane zostanie optymalne zapytanie SQL.

    Jako, że nigdy nie wyłączyłem Lazy Loading, nowością było dla mnie to co napisałeś:

    “Linia (@12) wyciąga z bazy tylko osoby, jeśli pole Properties będzie nullem.”

    Jeśli faktycznie tak jest, to jest to dla mnie jeszcze jeden argument, aby nie wyłączać LL. Dla mnie db.Person reprezentuje _całą_ kolekcje. Oczywiście db.Person.ToList() jest z reguły niedopuszczalne.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.