Robię mechanizm filtrowania i mam pewien problem. Główne dane potrzebne mi do tego wyciągam z trzech tabel (które oczywiście uzupełniam danymi z innych tabel połączonych z tymi tabelami), a następnie dodaje je do jednej, wspólnej listy klas (addRange()). Elementy w mojej głównej liście porządkuje np po dacie i biorę powiedzmy pierwsze kilka. Wszystko spoko tyle że w takim przypadku muszę te dane wszystkie wczytać z bazy. Jest to niepotrzebne ponieważ powiedzmy potem i tak wyświetlam po filtrach.
Rozwiązaniem problemu jest napisanie w taki sposób zapytania LINQ żebym nie musiał robić niepotrzebnych ToList(), tylko robię sobie union z trzech zapytań do bazy i selektem tworzę sobie wspólny typ anonimowy. Dzięki temu bez ściągania wszystkich danych porządkuje je sobie i pobieram tyle co potrzebuje. Wszystko mi działa tylko widzę tu kilka problemów.
Po pierwsze pisanie w ten sposób metod odzywających się do bazy jest beznadziejne. Mówimy tu o zapytaniu Linq które zajmuje mi spooooro linijek ~ 60. Przez to jest to strasznie słabo czytelne w porównaniu do utworzenia osobnych metod które pobierają różne dane i robią na nich operacje.
Zastanawiam się przez to, że coś tu jest nie tak, że musi być z tego jakieś wyjście a może pisanie takich długich zapytań w LINQ to coś normalnego. Nie wiem. W tym przypadku byłem zmuszony to zrobić jeżeli chciałem ładować tylko elementy które mnie interesują a nie ściągać wszystkich elementów i potem z nich wyświetlać te wybrane.
Drugi problem jaki napotkałem to metoda Count(), której też musiałem użyć, tylko w tym przypadku napisałem nowe zapytanie które robi select na idkach wszystkich elementów które mam do wyświetlenia bez ładowania żadnych danych. Mimo tego czas jego wykonania jest bardzo podobny co do czasu wykonania całego głównego(opisanego wyżej) zapytania LINQ.. Myślałem że to powinno działać szybciej..
Przy sporej liczbie danych przez metodę Count() metoda chodzi powoli.
Ja bym stworzył w takim przypadku widok na bazie zamiast robić tasiemce w LINQ, ale możesz też rozdzielać zapytania na mniejsze dopóki nie użyjesz zachłannego (ang. eager) operatora jak ToList, Count, Sum itp. to ORM powinien potrafić zbudować sobie całe zapytanie. Dochodzi tutaj jeszcze różnica między używaniem IEnumerable<T> a na przykład IQueryable<T> (do doczytania).
A co do dużej ilość Count, każde wywołanie takiego operatora jak i innych zachłannych powoduje że idzie zapytanie do bazy żeby tą wartość wyliczyć, więc jak masz wiele wywołań Count w zapytaniu w LINQ dla każdego idzie osobne zapytanie do bazy.
W moim przekonaniu pomysł widoku zaproponowany przez @DibbyDum to najlepszy rozwiązanie, ewentualnie możesz również skorzystać z "surowych" zapytań SQL - Entity Framework umożliwia taki feature.
Do poczytania: http://www.codeproject.com/Articles/206416/Use-dynamic-type-in-Entity-Framework-SqlQuery
W takim razie poczytam o widokach. Dzięki.
RideorDie napisał(a):
Po pierwsze pisanie w ten sposób metod odzywających się do bazy jest beznadziejne. Mówimy tu o zapytaniu Linq które zajmuje mi spooooro linijek ~ 60. Przez to jest to strasznie słabo czytelne w porównaniu do utworzenia osobnych metod które pobierają różne dane i robią na nich operacje.
A czemu nie stworzysz oddzielnych metod budujących do zapytanie? Np. jedne niech zrobią odpowiednie Include, inne nałożą Wherezwiązane z jednym rodzajem danych, inne z drugim (nie chodzi o typ danych, tylko np. filtrowanie po statusie zamówienia oraz datach może zostać umieszczone w oddzielnych metodach), a ostatnia niech zrobi Select.
Wydaje mi się, że takie coś jest do zrobienia z LINQ to Entities, a przynajmniej warto spróbować. Dużo małych, sensownie ponazywanych metod to zawsze dobra rzecz.