Zapytanie LINQ vs metody LINQ

Wszyscy chyba zdają sobie sprawę z tego, jakim dobrodziejstwem jest LINQ, które pojawiło się dosyć dawno, wraz z .NET 3.0 3.5. Jak wiadomo LINQ oferuje trochę nowych słów kluczowych oraz trochę metod – i tu pojawia się pytanie  – czym różni się zapis za pomocą słów kluczowych od zapisu „metodowego”? Szczególnie interesujące zdaje się być to, czy któryś z zapisów powoduje jakiś narzut wydajnościowy.

Nie będę budował napięcia i od razu odpowiem – query syntax w zasadzie nie różni się niczym od zapisu za pomocą extension methods. W praktyce, zapytanie zapisane za pomocą słów kluczowych jest tłumaczone podczas procesu kompilacji na coś, co CLR świetnie rozumie – metody. Microsoft, tak jak wielu programistów, preferuje zapis „zapytaniowy” nad „metodowym” ze względu na czytelność. Moim zdaniem jest to sprawa mocno dyskusyjna, dla mnie często dużo bardziej czytelniejsze jest używanie extension methods. Ponadto, niestety nie wszystko zapisywalne za pomocą extension methods da się zapisać za pomocą słów kluczowych, ale o tym za moment w przykładach.

Przykład 1

int[] numbers = { 5, 10, 8, 3, 6, 12 };

IEnumerable numQuery1 =
    from num in numbers
    where num % 2 == 0
    orderby num
    select num;

Taki kod równoważny jest (i jednocześnie tłumaczony w procesie kompilacji na następujący):

IEnumerable numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n => n);

Czy ten drugi nie wydaje się Wam czytelniejszy? ;) Nietrudno jednak stworzyć przykład w którym query syntax będzie bardziej wymowne.

Przykład 2

var personQuery1 = from person in people
                   let fullname = person.Name + " " + person.Surname
                   select new { Name = fullname, Age = person.Age };

var personQuery2 = people
                   .Select(person => new { Name = person.Name + " " + person.Surname, Age = person.Age });

W pierwszej linijce widzimy jak przydatne (dla czytelności) jest słowo kluczowe let pozwalające na tymczasową definicję nowej zmiennej (więcej o słówku let tu i tu na blogu Maćka Aniserowicza). Zapis za pomocą extension methods nie jest już taki ładny (choć to też zapewne sprawa gustu). Ostatni przykład zaprezentuje nam, że nie wszystko da się zrobić za pomocą query syntax.

Przykład 3

int[] numbers = { 5, 10, 8, 3, 6, 12 };
var nums = numbers.Skip(3).Take(2).ToList();

Efektu wywołania takich metod nie otrzyma się za pomocą zapytania.

Podsumowanie

Wszystko co da się napisać za pomocą query syntax da się zapisać za pomocą extension methods. Odwrotnie już tak niestety nie jest. Często zapis za pomocą słów kluczowych jest dużo czytelniejszy (szczególnie przy używaniu let, group, join), natomiast metody dają nam szersze możliwości. Wybór więc powinien zależeć od osobistego stylu i zdania na temat tego, co jest bardziej wymownie. Nieważne jednak czy korzystasz z metod, czy z zapytań, powinieneś robić to świadomie, aby nie tracić na wydajności – polecam przeczytać drugi z linków do blogu Maćka powyżej.

Prosty sposób na uaktualnienie GUI za pomocą BackgroundWorkera

Podczas pisania aplikacji okienkowych często zdarza się, że nasz program pobiera duże ilości danych, a następnie wyświetla je użytkownikowi. Niezwykle denerwującą sytuacją jest, gdy całość danych wyświetla się „na raz”. Jeśli nie „zamraża” to interfejsu użytkownika i jeszcze do tego pisze coś w stylu „Praca w toku” to jeszcze pół biedy, gorzej jak użytkownik pozostaje z okienkiem z uroczym dopiskiem „Nie odpowiada”. Wielkie szanse, że zirytowany taką sytuacją wyłączy naszą aplikację i zgłosi nam błąd – że nie działa :) Warto jednak zrobić coś jeszcze lepszego, niż zwykłe ostrzeżenie użytkownika, że troszkę poczeka.

Moim zdaniem najlepiej jest wprowadzić do aplikacji pasek postępu (choć nie zawsze jest to możliwe, bo czasem nie wiadomo ile danych przybędzie) i przede wszystkim – podzielić dane na paczki i prezentować dane progresywnie.

Jak to zrobić?

Najprostszym i przyjemnym sposobem jest użycie klasy BackgroundWorker, ale zacznijmy od początku. W celach demonstracyjnych stworzymy proste okienko, które będzie zawierało ListBox – do prezentacji wyników, przycisk „Start” oraz ProgressBar. Przejdźmy teraz do kodu:

private BackgroundWorker backgroundWorker = new BackgroundWorker();
private const int Results = 40;
private const int MaxPartCount = 5;

public PartialUpdateWindow()
{
    InitializeComponent();

    //initializing backgroundWorker
    backgroundWorker.DoWork += backgroundWorker_DoWork;
    backgroundWorker.ProgressChanged += backgroundWorker_ProgressChanged;
    backgroundWorker.RunWorkerCompleted += backgroundWorker_RunWorkerCompleted;
    backgroundWorker.WorkerReportsProgress = true;
}

Kod chyba jest bardzo wymowny. Tworzymy nową instancję BackgroundWorkera, dla prostoty przykładu ustalamy ile będzie wyników i ile ma liczyć maksymalna paczka danych do wyświetlenia. Następnie przypisujemy odpowiednie zdarzenia – DoWork – czyli to co ma zostać wykonane, ProgressChanged – zdarzenie odpalane w wątku GUI, które wyświetla wyniki, RunWorkerCompleted – odpalane po zakończeniu DoWork. Ostatnia linijka jest istotna, bo domyślnie ustawiona jest na false i wywołanie ProgressChanged skończy się wyjątkiem. Przejdźmy teraz do implementacji poszczególnych metod.

private void startButton_Click(object sender, RoutedEventArgs e)
{
    resultsListBox.Items.Clear();
    startButton.IsEnabled = false;
    backgroundWorker.RunWorkerAsync(Results);
}

Na początek funkcja podpięta pod przycisk która odpali naszego BackgroundWorkera. Jak widzimy do metody RunWorkerAsync, która uruchamia wątek możemy przekazać opcjonalnie argument. Może być on dowolnego typu i może być tylko jeden. W razie potrzeby, można zawsze przesłać tablicę lub inny kontener.

private void backgroundWorker_DoWork(object sender, DoWorkEventArgs e)
{
    int percentageComplete;
    List tempResults = new List();
    int partsCount;

    var random = new Random();

    for (var i = 1; i <= Math.Ceiling((int)e.Argument / (double)MaxPartCount); i++)
    {
        Thread.Sleep(random.Next(500, 1000)); //simulating data fetching

        if (i * MaxPartCount <= (int)e.Argument)
            partsCount = MaxPartCount; //send maximum
        else
            partsCount = (int)e.Argument - i * MaxPartCount; //send remaining

        for (var j = 0; j < partsCount; j++)
            tempResults.Add(random.Next());

        percentageComplete = (int)(((double)(i * MaxPartCount) / (int)e.Argument) * 100);

        backgroundWorker.ReportProgress(percentageComplete, tempResults);
    }
}

Teraz główna część naszego przykładu, czyli metoda podpięta pod DoWork. W środku tej metody tworzymy pętlę, która przebiega odpowiednią ilość razy (sufit ze wszystkich wyników podzielonych na maksymalna ilość części). Jak widzimy możemy się odwołać do przesłanego argumentu poprzez e.Argument. Musimy jednak stosować rzutowanie, gdyż e.Argument jest typu object (to dosyć oczywiste). W dalszych linijkach generujemy w losowym odstępie czasu po partsCount (równa MaxPartCount albo to co nie zostało jeszcze wysłane) liczb losowych, a także obliczamy procent wykonanej roboty. Kluczową częścią metody jest jej ostatnia linijka, która wywołuje w wątku GUI metodę podpiętą pod ProgressChanged. Do metody tej przekazujemy procent wykonanej pracy oraz znowu mamy opcjonalnie do przekazania jeden argument (ponownie typu object). To umożliwia nam sprytne użycie pozyskanych częściowych wyników - wysłanie ich do GUI. Dalsza część to już oczywistość:

private void backgroundWorker_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
    completeProgressBar.Value = e.ProgressPercentage;
    foreach (var item in (List)e.UserState)
        resultsListBox.Items.Add(item);
}

private void backgroundWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
    startButton.IsEnabled = true;
}

W backgroundWorker_ProgressChanged uaktualniamy stan ProgressBara oraz dodajemy pozyskane elementu do ListBoksa. Jest to możliwe gdyż, jak już wspomniałem, metoda ta wywoływana jest w tym samym wątku co GUI. Warto zwrócić uwagę na przekazany argument dostępny pod e.UserState - znów konieczne jest rzutowanie. Po skończonej pracy odblokowywujemy przycisk start i to tyle.

Podsumowanie

Widzimy, że rozwiązanie problemu częściowego uaktualniania interfejsu za pomocą BackgroundWorkera jest bardzo łatwe. To jest niewątpliwy plus. Ten sposób ma też (jak chyba wszystko ;)) jednak swoje wady. Po pierwsze, widać w kodzie, że w wielu miejscach musimy stosować rzutowanie z typu object na inny typ. Nie jest to operacja bezpieczna i przy jakichkolwiek zmianach w kodzie należy pamiętać aby pozmieniać też rzutowania w innych miejscach. Innym minusem jest utrudnione oddzielnie widoku od logiki, gdyż klasa BackgroundWorker pozostaje mocno powiązana z GUI.

Konicząc mój wywód - jeśli tworzysz małą aplikację lub pogodzenie się z minusami BackgroundWorkera nie jest szkodliwe dla Ciebie, ani dla tworzonego kodu - jak najbardziej polecam to rozwiązanie, bo po co pisać kod, który stworzył już ktoś wcześniej?