Pomijam fakt, że większość osób, którym robiłem techniczne review, jedyne typy kolekcji jakie znała to List<T>, Dictionary<K, V> i to właściwie wszystko (czasem jeszcze HashSet), to jest jeszcze jeden problem. Różne typy kolekcji są lepsze w niektórych przypadkach, a gorsze w innych. Głównie chodzi tutaj o performance. Ja wiem… Nie optymalizujemy za wcześnie. Niemniej jednak warto wiedzieć, które kolekcje sprawdzają się lepiej w konkretnych sytuacjach. W tym artykule robię zatem krótki przegląd większości kolekcji, jakie mamy do dyspozycji.
Dla maruderów
Nie opisuję tutaj rzeczy takich jak BitArray (i podobnych) ani kolekcji niegenerycznych. Niektóre klasy są wysoko wyspecjalizowane do konkretnych zadań (jak np. BitArray), a kolekcji niegenerycznych… po prostu nie powinniśmy raczej używać.
Jakie mamy kolekcje?
Pierwszy podział będzie ze względu na „thread safety”.
Kolekcje dla scenariuszy jednowątkowych
List<T>
To zdecydowanie najbardziej znana kolekcja w C#. Lista to po prostu tablica na sterydach i nic więcej. Elementy listy zajmują ciągły obszar w pamięci. Lista na dzień dobry rezerwuje sobie pewien obszar o wielkości określonej w Capacity (capacity to ilość elementów, jakie chcemy mieć, a nie wielkość wyrażona w bajtach). Gdy dodajemy nowe elementy i Capacity się kończy, wtedy lista rezerwuje nowy obszar w pamięci o rozmiarze Capacity * 2 (szczegół implementacyjny) i kopiuje tam swoje elementy. Itd. To oznacza, że dodawanie elementów do listy w pewnych sytuacjach może być kosztowne. Niemniej jednak jest najpopularniejszą kolekcją. Dostęp do elementu mamy przez jego indeks.
W skrócie:
kolejność elementów zachowana
elementy umieszczone w ciągłym miejscu w pamięci
może zawierać duplikaty
łatwy dostęp do poszczególnych elementów za pomocą indeksu
SortedList<K, V>
Lista sortowana. Coś w stylu połączenia List<V> z SortedDictionary<K, V>, chociaż nieco bliżej jej do słownika niż do listy. Elementy znajdują się wciąż w tablicach, czyli zajmują ciągłe miejsce w pamięci. Ale uwaga, kolekcja tak naprawdę zawiera dwie tablice – jedna trzyma klucze, druga wartości. Oczywiście wszystko ze sobą jest sprytnie zsynchronizowane. Uważam to jednak za szczegół implementacyjny, który być może kiedyś ulegnie zmianie.
Elementy są sortowane za pomocą klucza, czyli klucz powinien implementować interfejs IComparable<K>.
W skrócie:
elementy sortowane na podstawie klucza
elementy zajmują ciągłe miejsce w pamięci (osobne tablice dla kluczy i wartości)
nie może zawierać duplikatów
łatwy dostęp do poszczególnych elementów za pomocą indeksu
LinkedList<T>
To jest prawilna lista dwukierunkowa (kłaniają się struktury danych :)). Składa się z elementów (LinkedListNode<T>), które oprócz konkretnej wartości trzymają jeszcze referencje do następnego i poprzedniego elementu. Przez co pobieranie konkretnego elementu, np. 5tego może być nieco problematyczne, bo tak naprawdę wymaga przejścia przez wszystkie poprzednie elementy, aby uzyskać ten nas interesujący.
W skrócie:
kolejność elementów zachowana
elementy umieszczone w różnych miejscach w pamięci
może zawierać duplikaty
dostęp do poszczególnych elementów jest łatwy, ale może być wolniejszy
ObservableCollection<T>
To bardzo dobrze znają osoby piszące w WPF. Ta kolekcja po prostu daje Ci znać, kiedy coś się w niej zmieni. Tzn. element zostanie dodany, usunięty lub zamieniony. Pod spodem jest zwykła lista.
Queue<T>, Stack<T>
To po prostu typowa kolejka FIFO (queue) i stos LIFO (stack). Przydają się wtedy, kiedy chcemy się pozbyć elementu po zdjęciu go z kolekcji i chcemy mieć zapewniony konkretny porządek.
W skrócie:
queue to kolejka FIFO, a stack to stos LIFO
elementy umieszczone w ciągłym miejscu w pamięci
może zawierać duplikaty
element jest automatycznie zdejmowany po odczytaniu go z kolejki (stosu)
PriorityQueue<T, P>
Kolejka priorytetowa. Zawiera elementy typu T i priorytet typu P. Przydatna kiedy chcemy niektóre elementy w kolejce traktować priorytetowo.
W skrócie:
kolejka z priorytetem
brak kolejności elementów
może zawierać duplikaty
element jest automatycznie usuwany po odczytaniu go z kolejki
Dictionary<K, T>
Słownik to kolekcja, która przetrzymuje obiekty na podstawie jakiegoś klucza. Klucz jest obliczany za pomocą metody GetHashCode z obiektu typu K. A wartości to typy T. Wyróżnia się szybkim dostępem do danych. Oczywiście to jeszcze zależy jak napiszesz swoją metodę GetHashCode, ale trzymając się standardowych podejść, wszystko powinno być dobrze 🙂
Słownik może mieć tylko jeden wpis z danym kluczem. Jeśli spróbujemy dodać kolejny z kluczem, który już istnieje w słowniku, rzucony będzie wyjątek.
UWAGA! NIGDY nie przechowuj wartości zwracanej z GetHashCode między uruchomieniami aplikacji. Po zmianie wersji .NET (nawet minor albo build) może okazać się, że GetHashCode zwraca inne wartości. Microsoft nie daje gwarancji, że tak nie będzie. A i ja się miałem okazję kiedyś przekonać o tym, że nie można na tym polegać. GetHashCode jest użyteczne tylko w tej samej wersji frameworka.
W skrócie:
brak kolejności elementów
elementy umieszczone w różnych miejscach w pamięci
nie może zawierać duplikatów
szybki dostęp do elementu po kluczu
ReadOnlyDictionary<K, T>
Daję go w sumie jako ciekawostkę. To słownik tylko do odczytu. Każda zmiana elementów po utworzeniu tego słownika kończy się rzuceniem wyjątku. Ja zdecydowanie wolę posługiwanie się odpowiednim interfejsem (np. IReadOnlyDictionary) niż tym słownikiem.
SortedDictionary<K, T>
To po prostu słownik, który jest posortowany. Każdy element w słowniku jest sortowany na podstawie klucza. Jeśli klucz implementuje interfejs IComparable<K>, wtedy ten właśnie komparator jest używany do porównania wartości. Sortowanie odbywa się automatycznie po zmianie na liście elementów. Natomiast klucz musi być niezmienny.
Potrzebuje nieco więcej pamięci niż SortedList, za to operacje dodawania i usuwania elementów są szybsze.
W skrócie:
elementy są posortowane względem klucza
elementy umieszczone w różnych miejscach w pamięci
nie może zawierać duplikatów
szybki dostęp do elementu po kluczu
FrozenDictionary<K, V>
To jest nowość w .NET 8. Pisałem już o tym w tym artykule. Generalnie jest to słownik tylko do odczytu, który jest zoptymalizowany pod kątem szukania elementów. I naprawdę daje radę. Zresztą zobacz sobie porównanie w moim artykule o nowościach w .NET 8.
W skrócie:
brak kolejności elementów
elementy umieszczone w różnych miejscach w pamięci
nie może zawierać duplikatów
szybki dostęp do elementów po kluczu (szybszy niż w Dictionary<K, V>)
TYLKO DO ODCZYTU
HashSet<T>
To jest zbiór niepowtarzalnych elementów o typie T. „Powtarzalność” jest sprawdzana na podstawie metody GetHashCode. Można go uznać za coś w rodzaju słownika bez wartości.
W skrócie:
brak kolejności elementów
elementy umieszczone w różnych miejscach w pamięci
nie może zawierać duplikatów
szybki dostęp po kluczu
SortedSet<T>
To, podobnie jak HashSet, też jest formą zbioru. Ale SortedSet to struktura drzewa binarnego (czerwono-czarne drzewo binarne). Elementy są posortowane zgodnie z przekazanym w konstruktorze Comparerem (lub domyślnym, jeśli nie przekazano).
Utrzymuje porządek sortowania bez dodatkowego narzutu podczas dodawania lub usuwania elementów. Nie daje jednak bezpośredniego dostępu do konkretnego elementu. Są oczywiście rozszerzenia, które to umożliwiają, np. IEnumerable.ElementAt, jednak związane jest to z przechodzeniem przez drzewo. Zatem używaj tylko wtedy, jeśli potrzebujesz mieć posortowane elementy, gdzie dodawanie i usuwanie nie daje dodatkowego narzutu.
elementy posortowane według przekazanego lub domyślnego Comparera
elementy umieszczone w różnych miejscach w pamięci
nie może zawierać duplikatów
brak bezpośredniego dostępu do konkretnego elementu
struktura drzewiasta
FrozenSet<T>
Analogicznie jak FrozenDictionary. Tylko reprezentuje HashSet zoptymalizowany do odczytu.
W skrócie:
brak kolejności elementów
elementy umieszczone w różnych miejscach w pamięci
nie może zawierać duplikatów
szybki dostęp do elementów po kluczu (szybszy niż w HashSet<T>)
TYLKO DO ODCZYTU
Immutable*<T>
Jest do tego kilka kolekcji niezmienialnych, które są oparte dokładnie na tych wymienionych wyżej. Jednak… nie można ich zmienić. To znaczy, że jeśli np. umożliwiają dodawanie lub usuwanie elementów, to tworzą i zwracają tym samym zupełnie nową kolekcję, a oryginalna pozostaje bez zmian. Czyli przy każdym dodaniu/usunięciu, cała kolekcja jest kopiowana.
Kolekcje dla scenariuszy wielowątkowych
Tutaj najpierw słowo wstępu. Istnieje namespace System.Collections.Concurrent i to klasami z tego namespace powinniśmy się posługiwać jeśli chodzi o wielowątkowość. Są jeszcze inne kolekcje w innych namespace’ach (starszych), jak np. SynchronizedCollection opisane niżej. Ale tych raczej powinniśmy unikać, chyba że naprawdę z jakiegoś powodu musimy tego użyć.
SynchronizedCollection<T>
Czuję się trochę w obowiązku wspomnieć o tym starym tworze. TEORETYCZNIE to coś w rodzaju Listy do scenariuszy wielowątkowych. Jednak jego „thread-safe” ogranicza się tylko do tego, że każda operacja jest zamknięta w instrukcji lock. A blokowany jest obiekt dostępny przez SyncRoot.
Ostatecznie może to prowadzić do problemów w sytuacjach wielowątkowych, ponieważ operacje nie są atomowe. Czyli jeśli przykładowo próbujesz wykonać dwie operacje, które zasadniczo logicznie są jedną, wtedy może to prowadzić do poważnych problemów. Przykład?
Tutaj po wywołaniu metody Contains, wątek może się przełączyć i ostatecznie możesz skończyć z kilkoma takimi samymi elementami w kolekcji.
ConcurrentBag<T>
O, to chyba zasługuje na osobny artykuł. Ale krótko mówiąc, to taka kolejka, która działa najlepiej we wzorcu Producer-Consumer. Słowo „kolejka” jest tutaj bardzo dobrym wyznacznikiem, bo ConcurrentBag to kolejka. Tyle że to nie jest to ani LIFO, ani FIFO – ot taka kolejka o nieokreślonej kolejności 🙂
Kilka wątków (A, B, C) może wkładać do niej elementy. Kolejka ma swoją własną listę elementów dla każdego wątku. Jeśli teraz pobieramy z niej elementy w wątku A, a ConcurrentBag nie ma elementów dla wątku A, wtedy „kradnie” element z puli innego wątku. Tak to mniej więcej można opisać. Więc najlepiej sprawdza się, gdy wątek często obsługuje własne zadania. Wtedy jest najbardziej efektywny.
W skrócie:
brak zachowania kolejności elementów
elementy umieszczone w różnych miejscach w pamięci
może zawierać duplikaty
brak dostępu do konkretnego elementu, można jedynie pobrać kolejny element z kolejki
ConcurrentStack<T>, ConcurrentQueue<T>
To zasadniczo są odpowiedniki zwykłego Stack i Queue, tyle że wątkowo bezpieczne. Tzn., że różne wątki mogą zapisywać i odczytywać elementy z kolejek w tym samym czasie. Oczywiście elementy będą zdejmowanie zgodnie z porządkiem kolejki.
W skrócie:
queue to kolejka FIFO, a stack to stos LIFO
elementy umieszczone w różnych miejscach w pamięci – w przeciwieństwie do jednowątkowych odpowiedników
może zawierać duplikaty
element jest automatycznie zdejmowany po odczytaniu go z kolejki (stosu)
BlockingCollection<T>
To też jest rodzaj kolejki, ale nie musi. W swojej domyślnej postaci, w środku ma ConcurrentQueue<T>. Podczas tworzenia można jej podać maksymalną ilość elementów. Wtedy, jeśli jakiś wątek będzie chciał dodać kolejny element (gdy już cała kolekcja jest zapełniona), wątek zostanie wstrzymany aż inny pobierze coś z kolekcji i zwolni miejsce. W drugą stronę zadziała to podobnie – jeśli wątek będzie chciał pobrać coś z pustej kolekcji, to będzie czekał.
Podczas tworzenia kolekcji można podać dowolny „kontener” dla itemów, który implementuje interfejs IProducerConsumerCollection<T>.
W skrócie:
elementy mogą być różnie umieszczone w zależności od przekazanego wewnętrznego kontenera – domyślnie jest to ConcurrentQueue
może zawierać duplikaty (jeśli wewnętrzny kontener na to pozwala)
brak dostępu do dowolnego elementu – można tylko ściągnąć aktualny element
UWAGA! Tutaj występuje jeszcze taka metoda jak CompleteAdding(). Wywołanie jej mówi kolekcji: „Słuchaj misiu, już nikt Ci nigdy niczego nie doda, a jeśli będzie próbował, zdziel go w twarz wyjątkiem”. To kwestia optymalizacyjna. Jeśli kolekcja jest oznaczona w ten sposób, wtedy wątek, który próbuje coś pobrać przy pustej kolekcji, nie będzie czekał, bo wie, że już nic nie zostanie dodane.
ConcurrentDictionary<K, T>
Nie ma co tu dużo mówić. To po prostu zwykły słownik przeznaczony do scenariuszy wielowątkowych. Różne wątki mogą jednocześnie zapisywać i odczytywać elementy. Poza tym niczym szczególnym nie różni się od zwykłego Dictionary<K, T>.
To tyle jeśli chodzi o standardowe kolekcje, których możemy używać. Dzięki za przeczytanie artykułu. Jeśli czegoś nie zrozumiałeś albo znalazłeś w tekście jakiś błąd, koniecznie daj znać w komentarzu.
A, no i koniecznie podziel się tym artykułem z osobami, które znają jedynie listę i słownik 😉
W pewnym momencie powstał (a właściwie „został odkryty”) typ Span<T>. Nagle Microsoft zaczął go wszędzie używać, twierdząc że jest zajebisty. No dobra, ale czym tak naprawdę jest ten Span? I czy faktycznie jest taki zajebisty? Zobaczmy.
Jedno jest pewne. Używasz go, być może nawet o tym nie wiedząc (jest rozlany wszędzie we Frameworku).
Czym jest Span<T>?
Żeby była jasność. Span to NIE JEST kontener.
W zasadzie Span<T> to takie oczko, które gapi się na przekazany fragment pamięci:
I właściwie mógłbym na tym artykuł skończyć, bo obrazek powyżej idealnie oddaje sens i działanie Spanu. Ale ok, jeśli chcesz więcej, to czytaj dalej 🙂
Przede wszystkim musisz zrozumieć różnice między stosem i stertą. Jeśli nie jesteś pewien, koniecznie przeczytaj ten artykuł, w którym nieco nakreślam sytuację.
Span jako wskaźnik
Span<T> jest w pewnym sensie wskaźnikiem w świecie zarządzanym. Wskazuje na pewien obszar pamięci na stercie (zarządzanej i niezarządzanej). Ale może też wskazywać na pamięć na stosie. Pamiętaj, że jako wskaźnik, sam Span jest alokowany na stosie i zasadniczo składa się z dwóch elementów:
adresu miejsca, na który wskazuje
wielkości tego miejsca
Można by powiedzieć, że Span<T> wygląda mniej więcej tak:
public readonly ref struct Span<T>
{
private readonly ref T _pointer;
private readonly int _length;
}
Tak, mniej więcej taka jest zawartość spanu (+ do tego kilka prostych metod i rozszerzeń). Z tego wynika pierwsza rzecz:
Span jest niemutowalny (immutable) – raz utworzonego Spanu nie można zmienić. Tzn., że raz utworzony Span zawsze będzie wskazywał na to samo miejsce w pamięci.
W pamięci może to wyglądać mniej więcej tak:
Na stosie mamy dwie wartości, które składają się na Span. Pointer, jak to pointer, wskazuje na jakiś obszar w pamięci na stercie, natomiast length posiada wielkość tego obszaru. A co to za obszar? Ten, który wskażesz przy tworzeniu Spana.
Uniwersalność tworzenia
Utworzyć Spana możemy właściwie ze wszystkiego. Z tablicy, z listy, z Enumerable, a nawet ze zwykłego niskopoziomowego wskaźnika. To jest jego główna moc i jeden z powodów jego powstania.
I, powtarzam – Span to NIE JEST żadna kolekcja. To NIE JEST tablica. Span nie służy do przechowywania danych, tylko pokazuje Ci fragment pamięci z tymi danymi, które zostały zaalokowane gdzieś wcześniej.
A po co to?
Wyobraź sobie teraz, że masz listę intów, której elementy chcesz zsumować. Możesz przecież zrobić coś takiego:
static void Main(string[] args)
{
List<int> list = [1, 2, 3];
var value = Sum(list);
}
private static int Sum(List<int> source)
{
var sum = 0;
foreach (var item in source)
{
sum += item;
}
return sum;
}
I to zadziała super. Masz metodę, która sumuje jakieś dane.
Ok, a teraz załóżmy, że w pewnym momencie ktoś zamiast listy chce dać Ci tablicę. I czym to się kończy? Czymś takim:
static void Main(string[] args)
{
int[] arr = [1, 2, 3];
var value = Sum(arr.ToList());
}
private static int Sum(List<int> source)
{
var sum = 0;
foreach (var item in source)
{
sum += item;
}
return sum;
}
Czy to jest w porządku?
Spójrz co się dzieje w linii 4. TWORZYSZ listę. W sensie dosłownym – tworzysz zupełnie nowy obiekt (wywołując ToList()). Wszystkie wartości tablicy są kopiowane i jest tworzona nowa lista, która będzie obserwowana przez Garbage Collector na stercie zarządzanej.
Czyli masz już dwa obiekty obserwowane na tej stercie – tablicę i listę. Pamiętaj, że tworzenie obiektów na stercie jest stosunkowo kosztowne. Poza tym, gdy pracuje Garbage Collector, Twoja aplikacja NIE pracuje, tylko czeka.
I teraz z pomocą przychodzi Span:
static void Main(string[] args)
{
int[] arr = [1, 2, 3];
var span = new Span<int>(arr);
var value = Sum(span);
}
private static int Sum(Span<int> source)
{
var sum = 0;
foreach (var item in source)
{
sum += item;
}
return sum;
}
Co się dzieje w tym kodzie? Przede wszystkim zwróć uwagę, że metoda Sum w ogóle się nie zmieniła (poza typem argumentu, który przyjmuje). Span daje Ci możliwość iterowania bez żadnych przeszkód.
To, co zostało zmienione, to zamiast Listy na stercie, utworzony został Span. A gdzie? Na STOSIE! Ponieważ, jak pisałem na początku – Span to STRUKTURA i jako taka jest tworzona na stosie. Nie ma też narzutu związanego z kopiowaniem danych i tworzeniem obiektu na stercie.
Dlaczego nie ma narzutu związanego z kopiowaniem danych? Bo nic nie jest kopiowane – powtarzam – Span to wskaźnik – on wskazuje na obszar zajmowany przez dane w tablicy arr. I to jest też mega ważne – wskazuje na konkretne dane, a nie na cały obiekt. Innymi słowy, wskazuje na miejsce arr[0]. I to jest właśnie druga główna supermoc Spana (tak samo wskaże na początek danych listy itd).
Porównanie
Zróbmy sobie teraz małe porównanie. Span idealnie działa ze stringami, gdzie widać jego moc już na pierwszy rzut oka. Więc napiszmy sobie prostą apkę, która zwróci ze stringa jakieś obiekty. String będzie w tej postaci:
string data = "firstname=John;lastname=Smith";
Stwórzmy też wynikową klasę:
class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}
Aby wykonać to zadanie bez użycia Spana, napisalibyśmy kod mniej więcej taki:
private static Person ProcessDataUsingString(string data)
{
var values = data.Split(";"); //alokacja dwóch nowych stringów i tablicy
var firstName = values[0].Substring(values[0].IndexOf('=') + 1); //alokacja nowego stringu
var lastName = values[1].Substring(values[1].IndexOf('=') + 1); //alokacja nowego stringu
return new Person
{
FirstName = firstName,
LastName = lastName
};
}
Natomiast ze Spanem mogłoby to wyglądać tak:
private static Person ProcessDataUsingSpan(string data)
{
var span = data.AsSpan();
var fNameValues = span.Slice(0, span.IndexOf(';'));
var lNameValues = span.Slice(span.IndexOf(';') + 1);
var firstName = fNameValues.Slice(fNameValues.IndexOf('=') + 1);
var lastName = lNameValues.Slice(lNameValues.IndexOf('=') + 1);
return new Person
{
FirstName = firstName.ToString(), //alokacja nowego stringu
LastName = lastName.ToString() //alokacja nowego stringu
};
}
Zrobiłem Benchmark dla jednego takiego rekordu:
Method
Mean
Error
StdDev
Ratio
Gen0
Allocated
Alloc Ratio
ProcessWithString
48.81 ns
0.231 ns
0.193 ns
1.00
0.0421
264 B
1.00
ProcessWithSpan
26.69 ns
0.534 ns
0.525 ns
0.55
0.0179
112 B
0.42
Jak widać Span jest zdecydowanie bardziej wydajny. Nie tylko pod względem czasu wykonania, ale i alokacji pamięci. Właściwie jedyne alokacje, jakie się tu odbyły są już podczas tworzenia nowego obiektu Person – gdy przypisywane są konkretne nowe stringi do obiektu.
Span tylko do odczytu
Zwykły Span pozwala na zmianę konkretnych danych w pamięci. A jeśli jednak chciałbyś użyć jego bezpieczniejszej wersji, to możesz ReadOnlySpan. Działa dokładnie tak samo, tylko nie umożliwia zmiany danych.
I ta właśnie wersja jest zwracana przez stringa – czyli wciąż nie możesz zmienić raz utworzonego stringa (bez użycia kodu unsafe i niskopoziomowych wskaźników).
Możesz mieć tu teraz mały mindfuck – jak to span jest niemutowalny, ale można zmienić mu dane?
Span jest niemutowalny pod tym względem, że raz utworzony zawsze będzie wskazywał na ten sam fragment pamięci. Ale to, co jest w tej pamięci możesz zmienić (chyba że masz ReadOnlySpan). Zobaczysz to dalej w artykule.
Na co nie pozwala?
Nie można zmienić stringu
Jak już pisałem, Span nie pozwala na zmianę elementów stringu. String jest zawsze niemutowalny i nic na to nie poradzisz (poza niskopoziomowymi wskaźnikami).
Nie może być częścią klasy
Z tego powodu, że Span MUSI BYĆ alokowany na stosie, nie może być elementem klasy. W sensie właściwością, czy polem. Elementy klasy mogą być alokowane na stercie, a Span nie może, bo ma to zabronione. Za to Span może być częścią ref struct. Ale w takiej sytuacji musisz uważać.
Musisz używać go mądrze
Pamiętasz jak pisałem, że raz utworzony Span zawsze będzie wskazywał dokładnie to samo miejce w pamięci? Musisz wiedzieć, co masz w tym miejscu, żeby nie doszło do wykrzaczenia:
byte[] arr = [1, 2, 3];
var span = new Span<byte>(arr);
arr = null!;
GC.Collect();
span[0] = 10;
Spójrz, najpierw alokujemy pamięć na tablicę. Na stosie znajduje się adres do elementów tej tablicy (czyli zmienna arr). Tworzymy sobie Span dla tej tablicy – Span teraz wskazuje na elementy tablicy na stercie.
Następnie usuwamy naszą tablicę – w efekcie nic tego miejsca już nie używa. Garbage Collector w pewnym momencie może je wyczyścić albo mogą zostać tam zaalokowane inne rzeczy. Natomiast Span cały czas wskazuje na tę pamięć. I przypisując jakąś wartość możesz doprowadzić do Access Violation.
Więc pod tym względem musisz być uważny.
Nie możesz go używać w asynchronicznych operacjach
Jako, że każdy wątek ma swój oddzielny stos, a Stack jest alokowany na stosie, to nie może być używany w operacjach asynchronicznych. Jeśli potrzebujesz czegoś takiego, użyj Memory<T>. O tym może też coś napiszę.
Czy Span jest zajebisty?
To w sumie tylko narzędzie. Odpowiednio użyte może sprawdzić, że aplikacje w C# będą naprawdę wydajne. Niemniej jednak cieszę się, że coś takiego powstało, ponieważ to jest jedna z rzeczy, których brakowało mi trochę, a które używałem w innych językach. Czyli wskaźniki. I to bez użycia kodu unsafe 🙂
Dzięki za przeczytanie artykułu. Jeśli czegoś nie rozumiesz lub znalazłeś jakiś błąd, koniecznie daj znać w komentarzu 🙂
W pierwszej części artykułu opisałem podstawy mieszania języków – C# i C++. Skupiliśmy się tam nieco bardziej na stringach, które nie są tak oczywiste i czasem sporo z nimi zabawy. Dzisiaj będzie coś jeszcze mniej oczywistego – struktury. Jeśli jednak nie ogarniasz podstaw, koniecznie przeczytaj pierwszą część artykułu.
Język C++ jest tylko przykładowy. Za każdy razem, gdy piszę o funkcji lub strukturze C++, mam na myśli funkcję / strukturę pisaną w dowolnym języku niskiego poziomu (niezarządzanego) typu C, C++, Pascal.
Przypominam, że cykl jest dość zaawansowany. Wymaga trochę wiedzy na temat pamięci i wskaźników. Co nieco pisałem w tym artykule. Ale jeśli czegoś nie rozumiesz, to koniecznie daj znać w komentarzu.
Przykładowy projekt
Przygotowałem prostą solucję, którą możesz pobrać z GitHuba. To są dwa projekty – jeden C++, drugi C#. Projekt C++ to prosta biblioteka DLL, którą będziemy używać w C#. Nie ma żadnego konkretnego sensu. Napisałem ją tylko na potrzeby tego artykułu. Na dzień pisania artykułu (lipiec 2024) biblioteka nie jest w pełni ukończona. Będę dodawał jej funkcjonalność przy kolejnych częściach artykułu. Niemniej jednak, projekty się budują i działają w obrębie tego artykułu jak i jego pierwszej części.
Jeśli masz problem z uruchomieniem solucji, jest to dokładnie opisane w pierwszej części artkułu.
Struktury w pamięci
Niestety struktury zarządzane i niezarządzane są nieco inaczej rozłożone w pamięci. Dlatego też trzeba zastosować kilka dodatkowych środków, żeby to ładnie pożenić. Ale od początku.
Co ciekawe, nazwy struktur nie mają tutaj żadnego znaczenia. Po stronie C++ możesz mieć strukturę nazwaną UserInfo, natomiast po stronie C# to może być AdditionalUserData. Nie ma to żadnego znaczenia.
To, co faktycznie ma znaczenie, to pola w tych strukturach. Muszą być zdefiniowane dokładnie w takiej samej kolejności i muszą zajmować dokładnie tylko samo bajtów w pamięci:
ta sama kolejność pól
pola tej samej długości
Niestety nie ma opcji, żeby w czasie kompilacji sprawdzić to. Po prostu jeśli zrobisz coś źle, to aplikacja się wywali w runtime. Z tego wychodzi pierwsze niebezpieczeństwo, które wiele lat temu (gdy na muchy mówiłem jeszcze „ptapty”) pozbawiło mnie kilku dni życia. I wcale to nie jest takie oczywiste.
Atrybut StructLayoutAttribute
W C#, ze względów wydajnościowych, pola w strukturze czasami są zamieniane miejscami. I zupełnie inaczej wyglądają w pamięci niż w kodzie. Dlaczego? Bo procesor najłatwiej i najszybciej odczytuje bloki po 4/8 bajtów w pamięci. Dochodzi do tego jeszcze padding.
Czym jest padding?
Jak już pisałem, procesor najlepiej radzi sobie (najbardziej optymalnie) z blokami po 4/8 bajtów w pamięci. Zatem ile miejsca w pamięci zajmie taka struktura?
struct MyStruct
{
public bool b;
public int i;
}
Odpowiedź może Cię zdziwić. Pomimo, że zmienne typu bool potrzebują 1 bajta w pamięci, a int 4 bajtów, to taka struktura zajmie 8 bajtów, a nie 5. Dlaczego? Właśnie przez optymalizację. Gdy kompilator zobaczy zmienną typu bool, będzie chciał dokonać wyrównania (alignment), czyli zarezerwuje jej pamięć tak, żeby zmienna znajdowała się w 4 bajtowym bloku. Czyli dopełni do 4 bajtów. To dopełnienie nazywa się paddingiem. Int zajmuje już 4 bajty, czyli tutaj nic się nie stanie. Dokładniej rzecz biorąc nie chodzi konkretnie o 4 bajty, tylko o największy składnik w strukturze. Ale to już naprawdę głębokie szczegóły.
Zobacz, jak ta struktura wygląda w pamięci:
MyStruct mstr;
mstr.b = true;
mstr.i = 10;
Jeśli będziesz mieć taką strukturę:
struct MyStruct
{
public bool b;
public bool c;
public int i;
}
to ona też zajmie 8 bajtów. Kompilator zobaczy, że dwie pierwsze zmienne mają 2 bajty, więc dopełni je do 4. Czyli w tym przypadku nie ma różnicy, czy masz jedno pole typu bool, czy 4.
struct MyStruct
{
public bool b;
public int i;
public bool c;
}
Prawdę mówiąc, nie jestem w stanie odpowiedzieć na to pytanie. Różne ustawienia i wersje kompilatora mogą doprowadzić do różnych wyników. Jednym z nich jest zarezerwowanie 12 bajtów w pamięci (b + 3 bajty paddingu, i, c + 4 bajty paddingu). Innym jest pomieszanie pól w taki sposób, żeby uzyskać strukturę jak z poprzedniego kodu – czyli 2 zmienne bool będą w pamięci obok siebie.
Tylklo dla dociekliwych
Załóżmy, że mamy taką strukturę:
struct MyStruct
{
public bool b;
public bool c;
public int i;
}
Domyślna wielkość paddingu to 4 bajty. W związku z tym, że 2 pierwsze elementy zajmują dwa bajty, kompilator doda kolejne 2 bajty przed zmienną int. Dzięki czemu mamy 2 bloki po 4 bajty.
Jednak jeśli ustawiłbyś jawnie padding na wielkość 2 bajtów – żaden padding nie zostanie dodany – w tym konkretnym przypadku. Dwa pierwsze pola zajmują już 2 bajty. Czyli mamy tutaj blok o określonej wielkości.
A jeśli ustawimy padding na 8 bajtów? Też nic się nie stanie. I dlaczego do cholery? Dlaczego? Ponieważ obliczając wielkość wyrównania, kompilator bierze pod uwagę nie tylko tą żądaną wielkość, lecz również wielkość największego pola w strukturze. A skoro tutaj największym polem jest int – 4 bajty, zatem do tych 4 bajtów będzie dokładane dopełnienie. Oczywiście, jeśli struktura posiadałaby pole typu long (8 bajtów), wtedy zastosowany będzie padding 8 bajtów. W jaki sposób?
struct MyStruct
{
public bool b;
public bool c;
public int i;
public long l;
}
Pierwsze dwa pola zajmą 8 bajtów – każde z nich będzie dopełnione do 4. Kolejne pole – int zajmie 8 bajtów – zostanie dopełnione do 8, No i long ma już 8 bajtów.
A co się stanie, jeśli padding ustawimy na 1?
Żaden padding nie zostanie zastosowany i pola nie będą dopełniane. Ale o tym za chwilę.
I jak to się ma z tym, co wcześniej napisałem? Że struktury w C++ i w C# muszą mieć pola o tej samej wielkości i w tym samym porządku?
Po stronie C# służy do tego wspomniany atrybut StructLayout.
Jak używać StructLayout?
Atrybut StructLayout mówi kompilatorowi w jaki sposób ma potraktować daną strukturę w pamięci. Atrybut posiada 4 parametry:
LayoutKind
CharSet
Pack
Size
LayoutKind
Możemy tutaj ustawić 3 wartości:
Sequential – pola w strukturze będą ustawione dokładnie w takiej samej kolejności, w jakiej napisaliśmy w kodzie. Powinieneś użyć jeszcze parametru Pack, żeby określić dokładnie padding. I wtedy możesz przekazywać taką strukturę między światem niezarządzanym i zarządzanym.
[StructLayout(LayoutKind.Sequential, Pack = 1)] //Pack ustawiony na 1 zabrania dokonywania jakiegokolwiek paddingu
struct MyStruct
{
public byte b;
public byte b2;
public int i;
}
Explicit – pola w strukturze są tak ustawione, jak je określisz za pomocą atrybutów FieldOffset. To znaczy, że możesz dokładnie i jawnie (explicitly) podać w którym miejscu w pamięci ma się zacząć konkretne pole.
[StructLayout(LayoutKind.Explicit)]
struct MyStruct
{
[FieldOffset(0)] public byte b; //w bajcie 0
[FieldOffset(1)] public byte b2; //w bajcie 1
[FieldOffset(2)] public int i; //w bajcie 2
}
W tej sytuacji pole b będzie na początku struktury. b2 zacznie się w pierwszym bajcie, a i w drugim. Oczywiście musisz na to uważać, bo możesz zrobić głupotę:
[StructLayout(LayoutKind.Explicit)]
struct MyStruct
{
[FieldOffset(0)] public byte b;
[FieldOffset(2)] public byte b2
[FieldOffset(1)] public int i;
}
Pamiętaj, że pole int zajmie 4 bajty. Byte zajmie 1 bajt. I co się stanie teraz? Pole int przesłoni pole byte. I w zależności od tego, co przypiszesz jako ostatnie, będą różne dziwne wyniki. Więc jeśli stosujesz layout typu explicit, to uważaj na to.
Auto – domyślny układ – czyli pola mogą być w różnym miejscu z paddingiem.
Pack
Parametr Pack określa wielkość paddingu. Opisałem to w akapicie dla dociekliwych, więc nie będę tutaj się powtarzał. Wartość 0 jest domyślna, natomiast jeśli w ogóle nie chcesz paddingu, daj tam wartość 1.
Size
Określić tym możesz wynikowy rozmiar CAŁEJ struktury. Jeśli jednak podasz zbyt małą liczbę, to spokojnie. Struktura i tak zajmie swoją minimalną wymaganą przestrzeń.
Padding po stronie C++
Po stronie C++ też należy określić padding dla struktury. Tam stosujesz dyrektywę pragma pack:
Pobierzemy sobie wreszcie jakieś dane z C++. Na razie spójrzmy na struktury z polami kopiowalnymi (blitable). Jeśli nie pamiętasz, czym są takie pola, to jest to opisane w pierwszej części artykułu.
I teraz uwaga – jeśli w strukturze chcesz mieć jakieś metody – w niczym to nie przeszkadza. Dane przejdą normalnie.
Ten sam padding
Wcześniej pisałem, że procesor działa najbardziej optymalnie, gdy odczytuje bloki o odpowiedniej długości. Ustawiając padding na 1, wyłączamy go w ogóle i powodujemy, że kod nie jest super optymalny. Oczywiście w standardowych przypadkach to pewnie będzie niezauważalne.
Ale chcę żebyś miał świadomość, że to nie chodzi o to, żeby tego paddingu nie było w ogóle, tylko żeby był taki sam po stronie natywnej i .NET.
Czyli równie dobrze nasze struktury mogłyby wyglądać tak:
To po prostu nazwa pliku i rozmiar pliku. Istotne tutaj jest, że nazwa pliku jest przedstawiona jako statyczna tablica – tzn. tablica o stałej długości. W C# powinniśmy tę strukturę zadeklarować tak:
[StructLayout(LayoutKind.Sequential, Pack = 1, CharSet = CharSet.Unicode)]
public struct CppFileInfo
{
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 260)]
public string fileName;
public long fileSize;
}
Użycie StructLayout już znasz. Dodatkowo, w związku z tym, że w strukturze występują stringi, musimy w struct layout zaznaczyć, że te stringi są unicodowe. A są unicodowe, bo po stronie C++ mamy tablicę wchar_t, a nie char.
Ale druga rzecz jest taka, że w związku z tym, że łapiemy zwykłego stringa po stronie C#, musimy zrobić na nim Marshaling. W marshalingu zaznaczamy, że jest to string. Po stronie C++ mamy string w najczystszej postaci, więc musimy powiedzieć .NETowi, że właśnie tak ma traktować ten fragment pamięci. Rozmiar tego stringu ustawiamy na 260, bo taką wartość ma stała MAX_PATH.
I teraz możemy już wywołać funkcję, która zwróci nam informacje o jakimś pliku. Po stronie C++:
Zauważ, że tutaj CharSet też ustawiamy, ale on odnosi się do zmiennej, którą przekazujemy do C++, a nie do tej ze struktury.
Podsumowując, ze stringami w strukturach radzimy sobie dokładnie tak samo, jak ze zwykłymi stringami – opisanymi w poprzednim artykule. Wszystko dotyczące stringów jest prawdą i tutaj.
Tylko różnica jest taka, że odpowiedni Marshaling musimy ogarnąć na poziomie pola w strukturze, a nie na poziomie definicji funkcji.
To wszystko jeśli chodzi o przekazywanie struktur. W kolejnej części zajmiemy się klasami i wskaźnikami. Będzie zabawa 🙂
Jeśli znalazłeś błąd w artykule lub czegoś nie rozumiesz, koniecznie daj znać w komentarzu.
Czas akcji: 10 – 11.06.2024 Miejsce akcji: ICE Kraków (ul. Marii Konopnickiej 17, Kraków)
Gotowy na Code Europe — największy festiwal technologiczny w Polsce? 🎆
Hej, tegoroczna edycja Code Europe odbędzie się już w czerwcu w Krakowie. Tym razem będą to dwa dni konferencji, a więc warto sobie zabukować jakiś hotel. Jest to prawdopodobnie największa tego typu impreza w Polsce.
Byłem na Code Europe dwa lata temu ostatnim razem i potwierdzam, że było ciekawie. Niestety w tym roku nie będę mógł dołączyć, a szkoda, bo agenda wygląda całkiem fajnie, co możecie zobaczyć na oficjalnej stronie wydarzenia: https://www.codeeurope.pl/pl/
Prelegenci
Lista jest jak zwykle długa, ale możemy się spodziewać między innymi takich postaci jak:
Kenneth Rohde Christiansen – Intel
Ekaterina Sirazitdinova – NVidia, ekspertka od AI, która rozwijała m.in. analizy medyczne oparte na obrazach
Michelle Sandford – ewangelistka z Microsoftu
Shaundai Person – Netflix
dr Robert Gentleman – Harvard Medical School – współtworzył język R, mocno związany z biomedycyną
i inni.
Czemu warto?
/akapit organizatora/
Code Europe to nie tylko zwykłe wydarzenie IT — to miejsce, gdzie najlepsi eksperci z całego świata gromadzą się, by dzielić się wiedzą, wymieniać doświadczeniami i przekraczać granice technologii, a to wszystko w otoczce festiwalowej zabawy!
To Twoja szansa, by odkryć najnowsze trendy i nawiązać kontakty, które mogą kształtować Twoją przyszłość zawodową w branży technologicznej. Z ponad 15 000 już zaangażowanych uczestników, możesz być pewien, że każda chwila spędzona na Code Europe będzie wartościowa i zdecydowanie nie chcesz tego przegapić!
Code Europe zabłyśnie na ICE Kraków 10-11 czerwca 2024 r. Festiwal jest dla wszystkich entuzjastów technologii, deweloperów, architektów oprogramowania, specjalistów DevOps, zapaleńców bezpieczeństwa, profesjonalistów ds. produktu, specjalistów ds. danych i pasjonatów QA, którzy chcą dzielić się wiedzą i razem ją zdobywać!
Dlaczego warto być częścią Code Europe?
🚀 Unikalne spojrzenie: ucz się od najlepszych prelegentów, którzy dzielą się najświeższymi spojrzeniami i doświadczeniami z branży technologicznej.
🤝 Networking: poznaj innych entuzjastów technologii, współpracuj nad pomysłami i nawiąż kontakty, które mogą wpłynąć na Twoją dalszą ścieżkę kariery.
💼 Paliwo karierowe: odkryj możliwości, połącz się z gigantami branży i zdobądź wgląd w najgorętsze trendy i możliwości w branży IT i technologii.
🎤 Najlepsi prelegenci: przygotuj się na prelekcje z liderami technologicznymi takimi jak Venkat Subramaniam, José Valim, Sébastien Chopin, Sven Peters, Michelle Sandford i wielu, wielu innych!
UWAGA! Zniżka!
CodeEurope jest oczywiście płatnym eventem. Jednak moi subskrybenci dostają 20% zniżki na bilety. Zniżka już poleciała do Was w osobnym mailu 🙂
Jeśli jeszcze nie subskrybujesz, koniecznie zapisz się na newsletter, a też dostaniesz kod zniżkowy 🙂
Jeśli Twoja apka używa WebAPI, warto zatroszczyć się o ponawianie żądań HTTP właśnie do tych API. Stosuje się to z kilku powodów, o których piszę niżej.
W tym artykule przedstawię Ci najlepsze praktyki, jakie możesz wykorzystać.
O tworzeniu własnego klienta WebAPI i różnych uproszczeniach, które możemy zastosować, pisałem już w tym artykule. Ten, który czytasz, potraktuj jako rozszerzenie i coś, co warto zastosować w prawdziwym kodzie.
Jeśli jesteś zainteresowany tylko konkretnym rozwiązaniem, rozwiń poniższy akapit:
Teraz możesz już używać HttpClienta otrzymanego z dependency injection w standardowy sposób. Wszystko załatwia pobrana biblioteka i metoda AddTransientHttpErrorPolicy.
Jeśli chcesz wiedzieć więcej, przeczytaj cały artykuł.
Po co ponawiać żądania?
Jeśli pobierasz jakieś dane z WebApi możesz spotkać się z kilkoma odpowiedziami poza poprawną. Wtedy masz dwie opcje – pokazać użytkownikowi błąd. No i cześć. Albo spróbować ponowić żądanie, może za drugim razem się uda, a doświadczenie użytkownika z Twoją aplikacją będzie lepsze.
Odpowiedzi, po których warto ponowić żądanie to na przykład:
Wewnętrzny błąd serwera
Czyli kody odpowiedzi 5xx.
Oznacza to, że serwer ma aktualnie problem ze sobą. Mamy nadzieję, że chwilowy. W najgorszym wypadku, programiści czegoś nie przewidzieli i kod po prostu się wywala. Jeśli jednak jest to chwilowy problem, warto spróbować ponowić żądanie. Być może problem za chwilę zniknie.
Throttling
Kod 429: Too Many Requests.
Ten problem oznacza, że klient (Twoja aplikacja) zbyt często odpytuje serwer. Serwer ma ustawiony jakiś rate limit, co oznacza że możemy do niego strzelić określoną ilość razy w określonym czasie. To może być też ograniczone do ilości przesłanych danych. Więc jeśli otrzymasz odpowiedź 429 oznacza to, że za jakiś czas powinieneś ponowić żądanie i będzie git.
A co przy braku szukanego zasobu, skoro został utworzony?
Stare, dobre 404.
No… tutaj ponawianie ma sens tylko w jednej sytuacji. Kiedy wcześniej próbowałeś stworzyć zasób, ale to chwilę może zająć. A samo WebApi jest asynchroniczne. O asynchronicznych WebApi pisałem w tym artykule. W innym wypadku powtarzanie żądania przy tym kodzie nie ma żadnego sensu. Czyli zasadniczo nie powinieneś dostać takiej sytuacji, jeśli poprawnie obsługujesz asynchroniczne WebApi.
Ponawianie żądania – z czym to się je?
Zasadniczo sytuacja jest ciekawa. Bo nie ma innej opcji jak tylko ponawianie żądania w jakiejś pętli. Jednakże można to robić zarówno źle jak i dobrze. I źle to np. samemu tworzyć takie mechanizmy.
I możesz napisać sobie coś najprostszego w stylu (tylko fragment kodu):
To oczywiście nie dość, że ciężko jest reużyć, to jest brzydkie. Nie dość, że jest brzydkie, to sam musisz oprogramować jakieś standardowe zachowania. Sam musisz:
napisać kolejne mechanizmy do ponawiania requestu,
pilnować, czy nie ponawiasz requestu nieskończoną ilość razy,
pilnować, czy ponawiasz go dostatecznie długo, ale nie za długo,
napisać coś, co pozwoli Ci ponawiać request po jakimś delayu, a nie od razu,
i pewnie mnóstwo innych rzeczy.
Wpadasz w dużą ilość pułapek, zaczynasz trafiać na mnóstwo zduplikowanego kodu i koniec końców okazuje się, że tworzysz jakiś skomplikowany mechanizm albo nawet cały projekt, którego jedynym zadaniem jest tak naprawdę ponowienie requestu w pewnych warunkach… Zamiast skupić się na faktycznej robocie.
Co jaki czas ponawiać request?
Na to pytanie będziesz musiał odpowiedzieć sobie tak, czy inaczej. Nie możesz ponawiać requestu bez żadnej przerwy, np. tak
ten kod jest pozbawiony kluczowych elementów (np. sprawdzania kodu odpowiedzi)
zakładamy, że posiadamy tutaj ochronę przed nieskończoną rekukrencją
Tutaj będziesz ponawiał requesty jeden za drugim bez żadnej przerwy. Nie jest to dobre podejście, bo bombardujesz zupełnie bez sensu API. No i nie dajesz odetchnąć procesorowi.
Requestów wyjdzie od Ciebie duuużo mniej i będą dużo bardziej sensowne. No bo jeśli uzyskałeś odpowiedź 429, to mało prawdopodobne, że od razu w następnym requeście otrzymasz poprawną. Odczekaj chwilę – dokładnie to mówi ten błąd: „Wstrzymaj konie kowboju, daj odetchnąć… albo wykup wyższy pakiet dostępu”.
To samo tyczy się innych kodów, które warto ponawiać.
Takie „stałe” (co jedną sekundę) ponawianie pewnie jakoś wygląda i pomaga. Natomiast można to zrobić duuuużo lepiej.
Jitter
Jitter (możesz wyszukać w necie pod hasłem „retry with jitter”) to pewna zmienna, która pomaga lepiej ustalić ten czas. To może być jakaś losowość, czyli raz czekasz sekundę, raz czekasz dwie, raz czekasz pół.
Ale to może być też exponential backoff.
Exponential backoff
Zapamiętaj to pojęcie dobrze, bo może pojawiać się na pytaniach rekrutacyjnych 😉
Exponential backoff to ogólnie przyjęta strategia do obliczania czasu, jaki musi minąć pomiędzy ponawianiem konkretnego żądania. Polega na tym, że pierwsze ponowienia są dość szybko, a kolejne mają coraz większą przerwę. Zobacz ten prosty przykład ponawiania requestu w pseudokodzie:
Jeśli pierwszy request trzeba ponowić, odczekaj sekundę.
Jeśli i to nie poszło, odczekaj 2 sekundy.
Jeśli nadal nie działa, odczekaj 4 sekundy… (to jest potęgowanie) Itd.
Jest to dość eleganckie rozwiązanie i szeroko stosowane.
Oczywiście nie musisz tego wszystkiego robić sam. W .NET jest paczka, która całą tą czarną robotę z ponawianiem requestów robi za Ciebie. I to jest prawidłowy mechanizm i bardzo dobra praktyka.
Przywitaj Polly
Jest taki Nuget:
Użycie tej paczki bardzo ułatwia całą pracę, co za chwilę zobaczysz, ale można jeszcze prościej (co zobaczysz później).
Polly przedstawia mechanizm AsyncPolicy, w którym po prostu budujesz sobie politykę ponawiania requestów. Oczywiście politykę możesz zbudować raz i używać ją wszędzie albo możesz też mieć różne polityki. Zbudujmy swoją pierwszą polityke:
private readonly IAsyncPolicy<HttpResponseMessage> _retryPolicy =
Policy<HttpResponseMessage>
.Handle<HttpRequestException>()
.OrResult(x => (int)x.StatusCode >= 500 || x.StatusCode == HttpStatusCode.TooManyRequests)
.RetryAsync(3);
//wywołanie requestu nieco się teraz zmienia:
public async Task<HttpResponseMessage> SendRequest()
{
return await _retryPolicy.ExecuteAsync(() => _httpClient.GetAsync("api/get-data"));
}
W pierwszych linijkach stworzyliśmy politykę ponawiania requestów. To jest bardzo prosty builder i ma oczywiście dużo więcej możliwości niż tylko to, co pokazałem. Ale nie chcę w tym artykule pisać dokumentacji Polly, którą znajdziesz tutaj 🙂
Generalnie to mówi tyle:
IAsyncPolicy<HttpResponseMessage> – stwórz politykę dla typu zwracanego HttpResponseMessage
Handle<HttpRequestException> – użyj, jeśli pójdzie exception typu HttpRequestException (handle exception)
OrResult…. – lub rezultatem będzie – i tu przekazany delegat
RetryAsync(3) – ponów taki request 3 razy
I zobacz teraz co się stało w metodzie SendRequest. Została tylko jedna linijka, a mamy załatwione ponawianie requestu dla konkretnych StatusCode’ów i dla exceptiona, który może być rzucony. Wszystko się dzieje wewnątrz metody ExecuteAsync. My tylko musimy przekazać jej funkcję, która ma zostać wykonana – czyli konkretny strzał do API.
ExecuteAsync zwróci HttpResponseMessage, ponieważ z takim typem została zadeklarowana nasza polityka.
Jednak tak stworzona polityka nie jest idealna, bo będzie ponawiała request za requestem bez żadnej przerwy. Czy możemy dodać jakiś delay? Oczywiście, że tak:
Tutaj metodę RetryAsync zamieniliśmy na WaitAndRetryAsync. Ta metoda w pierwszym parametrze przyjmuje ilość żądanych powtórzeń – tak jak RetryAsync, natomiast w drugim podajesz czas jaki ma upłynąć przed kolejnymi powtórzeniami.
Drugim parametrem jest oczywiście funkcja, która ten czas oblicza. W parametrze funkcji dostajesz zmienną int – retryCount, która Ci mówi, które powtórzenie aktualnie się odbywa. Za pomocą tej informacji w bardzo łatwy sposób możemy stworzyć swój exponential backoff, co zostało zrobione w tym kodzie.
Wygląda skomplikowanie? Jasne, że można prościej.
Rozszerzenia do Polly
W Nuget znajdziesz różne rozszerzenia do Polly, między innymi Polly.Contrib.WaitAndRetry. Celem tego rozszerzenia jest dostarczenie Ci już gotowych mechanizmów „backoff”, czyli tych do obliczania czasu między powtórzeniami żądania. I powyższy kod może być zamieniony na taki:
W rozszerzeniu Polly.Contrib.WaitAndRetry dostaliśmy klasę Backoff i metodę ExponentialBackoff, której przekazaliśmy dwa parametry:
jaki czas musi upłynąć przed PIERWSZYM ponowieniem (tutaj sekunda)
ile razy ponawiać
Jest jeszcze lepsza metoda – do exponential backoff można dodać element losowości. Czyli przerwy nie będą idealnymi potęgami dwójki, ale będą trwały trochę mniej lub trochę więcej:
Jak widzisz, w bardzo łatwy sposób możesz zmieniać sobie strategie liczenia czasu.
Ale można jeszcze prościej… 😉
Integracja .NET z Polly
Microsoft w całej swojej dobroci zrobił już integrację z Polly, dzięki czemu możemy używać tego mechanizmu właściwie bez większych zmian w kodzie. Wszystko jest wpięte do HttpClientFactory, o którym pisałem trochę w artykule jak używać HttpClient.
Przede wszystkim pobierz sobie NuGeta: Microsoft.Extensions.Http.Polly. On ma już wszystkie zależeności.
Teraz, gdy rejestrujesz swojego klienta Http:
builder.Services.AddHttpClient<IndexModel>((client) =>
{
client.BaseAddress = new Uri("https://example/com/");
});
Powtarzanie requestu w konkretnych warunkach jest na tyle pospolite, że Microsoft zrobił dodatkowe rozszerzenie do tego. Metoda AddTransientHttpErrorPolicy dodaje politykę domyślnie ustawioną na:
obsługę exceptiona typu HttpRequestException,
obsługę rezultatu, gdy status >= 500
obsługę timeout.
Musimy dodać tylko backoff jaki chcemy mieć (czyli ten delay pomiędzy powtórzeniami).
Ale uwaga. Uważny czytelnik zorientował się, że metoda AddTransientHttpErrorPolicy nie dodaje do polityki statusu kodu 429 Too may requests. Zgadza się. Jeśli chcemy to mieć, musimy sami to dodać:
Przyznasz jednak, że rozwiązanie jest duuużo bardziej czytelne i dużo lepsze niż mechanizmy, które tworzyłbyś sam, prawda? W zasadzie cały ten mechanizm ograniczył się do wywołania trzech metod przy konfiguracji. Piękna sprawa.
To tyle. Dzięki za przeczytanie artykułu. Jak zwykle, jeśli czegoś nie rozumiesz lub znalazłeś błąd w tekście, koniecznie daj mi znać w komentarzu.
A i sprawdź swoje apki, gdzie używasz zewnętrznych Api. Czy w którejś z nich masz czasem problem z dostępnością?
Czy Twoja webówka działa? A jaką masz pewność? Musiałbyś co chwilę klikać i sprawdzać. Ale są też inne, lepsze metody. Możesz na przykład posłużyć się rozwiązaniem chmurowym, które cyklicznie będzie badać stan Twojej aplikacji. Co więcej, jest opcja, że nawet wyśle Ci maila albo SMSa, jeśli coś będzie nie tak.
Ten artykuł nie opowiada jednak o chmurowej części rozwiązania (jeśli chcesz taki materiał, daj znać w komentarzu), a o aplikacyjnej części. Czyli o healthcheck.
Czym jest Healthcheck?
Healthcheck jest sprawdzeniem stanu Twojej aplikacji. Czy działa wszystko ok, ewentualnie co nie działa. I oczywiście mógłbyś napisać sobie własny kontroler z odpowiednimi endpointami, w których to wszystko sprawdzasz, ale w .NET mamy już taki mechanizm w standardzie. I działa całkiem przyzwoicie.
Po co to właściwie?
Dzisiaj utrzymanie niezawodności i ciągłości działania aplikacji jest priorytetem. Stworzenie skutecznego mechanizmu healthcheck pozwala na szybką reakcję w razie wystąpienia jakiś problemów z jednym z kluczowych elementów systemu.
Jak już pisałem wcześniej, można to nawet spiąć z chmurą i spodziewać się maila albo nawet SMS gdy tylko coś niedobrego zacznie się dziać w Twojej aplikacji.
Przykładowa apka
Do tego artykułu stworzyłem przykładową aplikację, którą możesz pobrać z GitHuba. Po jej pobraniu, koniecznie uruchom migracje Entity Framework.
Niech nasza aplikacja zwraca różne dane pogodowe. Jeśli chodzi o prognozy, będą pobierane z zewnętrznego serwisu, a jeśli chodzi o dane archiwalne (prognoza z przeszłości), będą pobierane z naszej bazy danych.
Zewnętrzny serwis to oczywiście jakiś mock, który będzie udawał połączenie z zewnętrznym API.
Konfiguracja healthcheck
Podstawowa konfiguracja jest zabójczo prosta, bo sprowadza się tylko do rejestracji odpowiednich serwisów i dodania middleware. Czyli mamy coś takiego:
builder.Services.AddControllers();
//healthcheck
builder.Services.AddHealthChecks();
var app = builder.Build();
// Configure the HTTP request pipeline.
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapHealthChecks("/_health");
app.MapControllers();
app.Run();
Jeśli chodzi o linię 4 – to dodajemy do dependency injection serwisy do sprawdzenia stanu zdrowia. Co się tyczy linii 13, to mapujemy te healthchecki do konkretnego endpointa. W parametrze przekazujemy, pod jakim adresem ma być ten healthcheck. W tej sytuacji to będzie https://localhost:pppp/_health, gdzie pppp to oczywiście numer portu na środowisku lokalnym.
Teraz jeśli uruchomimy aplikację i sprawdzimy ten healthcheck, dostaniemy zwrotkę ze StatusCode 200 OK i wartością:
Healthy
Przyznasz jednak, że takie sprawdzenie niewiele nam daje. No właśnie, domyślny mechanizm właściwie niczego nie sprawdza. Jeśli aplikacja chodzi, to zawsze zwróci Healthy. A my chcemy sprawdzić przynajmniej dwie rzeczy:
czy działa połączenie z bazą danych
czy działa połączenie z zewnętrznym serwisem
Możemy wszystko napisać ręcznie, ale jest lepsza metoda. Nudesy…eeee Nugetsy 😉 O tym za chwilę.
Jak działa mechanizm healthcheck?
Metoda AddHealthChecks zwraca nam interfejs IHealthChecksBuilder, dodając jednocześnie domyślny serwis do sprawdzenia HealthChecków, który wszystkim zarządza. I tak naprawdę możemy sobie stworzyć listę healthchecków, jakie chcemy mieć. To wszystko sprowadza się do dodania do tego buildera klasy, która implementuje odpowiedni interfejs (o tym też będzie za chwilę).
Potem ten domyślny serwis bierze sobie te wszystkie klasy, tworzy je i wywołuje po kolei metodę sprawdzającą. Ot, cała magia. Dzięki czemu możemy tworzyć sobie właściwie nieograniczone sprawdzenia stanu zdrowia apki.
Badanie standardowych serwisów
Jeśli wejdziesz sobie do managera nugetów i zaczniesz wpisywać AspNetCore.Healthchecks, oczom Twym ukaże się całkiem pokaźna lista z już oprogramowanymi sprawdzeniami do konkretnych serwisów:
To nie są w prawdzie oficjalne Microsoftowe paczki, jednak społeczność która za tym stoi, to (w momencie pisania artykułu) ponad 150 osób. Jeśli używasz jakiegoś standardowego serwisu, to jest duża szansa, że sprawdzenie healthcheka do niego już istnieje.
Sprawdzanie bazy danych
Oczywiście możemy sobie sprawdzić różne bazy danych, w tym MSSQL, Postgre, MySQL, Redis itd. – używając bibliotek z powyższej listy. Możemy też użyć oficjalnej paczki Microsoft.Extensions.Diagnostics.Healthcheck, która umożliwia testowanie całego kontekstu bazy danych (EFCore). A jak używać tych wszystkich bibliotek?
Metoda AddHealthChecks zwraca nam interfejs IHealthChecksBuilder i wszystkie rozszerzenia jakie mamy dostępne są rozszerzeniami właśnie tego interfejsu. A prostymi słowami:
//healthcheck
builder.Services.AddHealthChecks()
.AddDbContextCheck<AppDbContext>(); //rozszerzenie z Microsoft.Extensions.Diagnostics.Healthcheck
W taki sposób możemy dodać sprawdzenie, czy baza danych działa. Domyślnie, sprawdzane jest połączenie z bazą danych za pomocą metody dbContext.Database.CanConnectAsync(cancellationToken);
Jednak niech nie zwiedzie Cię ta pozorna prostota. Jeśli chodzi o bazę MSSQL, to ta metoda faktycznie próbuje połączyć się z bazą danych, a potem wysyła zapytanie SELECT 1.
Oczywiście można zrobić więcej – wystarczy dodać jakieś parametry, np.:
W tym momencie domyślne sprawdzenie zostanie zamienione na nasze. Czyli podczas sprawdzenia stanu zdrowia bazy danych, baza zostanie odpytana o ilość rekordów w tabeli WeatherArchives – którą mamy zdefiniowaną w naszym AppDbContext. Parametr CustomTestQuery to po prostu funkcja, która przyjmuje w parametrze nasz kontekst bazy danych i CancellationToken, a zwraca jakiś bool.
I co najważniejsze – ten kod wystarczy. Nie trzeba tutaj stosować żadnych try..catch’y, ponieważ cała nasza funkcja i tak jest wywoływana w kontekście try..catch. Więc jeśli wystąpi jakiś exception, mechanizm healthcheck zwróci nam odpowiednią informację.
Niemniej jednak przy standardowych zastosowaniach, standardowy mechanizm sprawdzania bazy danych jest w zupełności wystarczający.
Sprawdzanie niestandardowe
Jednak nasz przykładowy serwis ForecastService, który ma imitować klienta jakiegoś zewnętrznego API, jest niestandardowym serwisem i nie znajdziemy biblioteki dla niego. Mechanizm HealthCheck pozwala jednak na napisanie własnego HealthChecka – dokładnie w taki sam sposób w jaki powstają te biblioteki wyżej pokazane.
Utworzenie klasy do sprawdzenia zdrowia
W pierwszej kolejności musimy utworzyć klasę, która implementuje interfejs IHealthCheck. Interfejs ma tylko jedną metodę, którą musimy napisać.
Teraz załóżmy, że nasz serwis, który udaje klienta API do pobierania prognozy pogody wygląda tak:
public class ForecastService(RandomHelper _randomHelper)
{
public async Task<WeatherData> GetForecastFor(string city, DateOnly date)
{
await Task.Delay(500);
return new WeatherData
{
City = city,
Date = date,
TemperatureC = _randomHelper.GetRandomTemperature()
};
}
public async Task<bool> IsServiceHealthy()
{
await Task.Delay(500);
return true;
}
Czyli sprawdzenie stanu zdrowia tego serwisu będzie wymagało tylko wywołania metody IsServiceHealthy, którą nam daje nasz oszukany klient. A jak to zrobić? No oczywiście w klasie implementującej IHealthCheck:
public class ForecastServiceHealthCheck(ForecastService _forecastService) : IHealthCheck
{
public async Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context,
CancellationToken cancellationToken = default)
{
var result = await _forecastService.IsServiceHealthy();
if (result)
return HealthCheckResult.Healthy();
else
return HealthCheckResult.Unhealthy();
}
}
W metodzie CheckHealthAsync musimy teraz zwrócić HealthCheckResult – rezultat, który mówi, czy testowany podsystem jest zdrowy, czy nie. Domyślne stany Healthy i Unhealthy zazwyczaj wystarczą.
Oczywiście w klasie implementującej IHealthCheck możesz zrobić dowolny kod. Jeśli masz faktyczne zewnętrzne API, do którego się łączysz, możesz mieć tutaj po prostu HttpClienta, za pomocą którego wyślesz jakiś request.
I tak jak pisałem wcześniej – takich klas możesz sobie utworzyć tyle, ile potrzebujesz.
Czyli wywołujemy metodę AddCheck. W parametrze generycznym przekazujemy typ klasy, w której zaimplementowaliśmy sprawdzenie, a w parametrze Name przekazujemy jakąś nazwę dla tego sprawdzenia. W tym wypadku: "Forecast service", bo sprawdzamy działanie właśnie tego serwisu.
Pokazywanie większej ilości informacji
W tym momencie, jeśli strzelimy na końcówkę z healthcheckiem dostaniemy odpowiedź w formie czystego stringa – Healthy albo Unhealthy. Ale możemy to zmienić w dość łatwy sposób. Najprościej pobrać sobie Nugeta: AspNetCore.Healthchecks.UI.Client i podczas dodawania healthchecków do middleware dodać opcje:
app.MapHealthChecks("/_health", new HealthCheckOptions
{
ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse //UIResponseWriter pochodzi z ww. Nugeta
});
I teraz dostaniemy dużo więcej informacji. Np. przy działającej aplikacji:
Zwróć uwagę, że otrzymujemy główny status apki i statusy poszczególnych serwisów, które sprawdzamy. AppDbContext to oczywiście sprawdzenie bazy danych. A Forecast service – to jest to, co sami pisaliśmy. Przy błędzie możemy uzyskać coś takiego:
Generalnie właściwość ResponseWriter przy mapowaniu tych healthchecków daje nam opcje takiego stworzenia odpowiedzi jaką chcemy. Jeśli ta domyślna z Nugeta daje za mało info albo trochę za dużo, sami możemy coś pokombinować, np.:
ResponseWriter to po prostu funkcja, która dostaje w parametrze HttpContext i HealthReport, a zwraca Task. Jej zadaniem jest wypisanie do responsa tego, co chcemy zobaczyć w odpowiedzi na ten endpoint.
Więc możemy sobie tutaj skonstruować odpowiedź jaka nam się tylko podoba. Możemy np. napisać sobie funkcje, która zwróci nam informacje o wersji albo co sobie tam wymyślimy.
Dodatkowe możliwości
Jeśli przyjrzysz się metodzie AddCheck z IHealthCheckBuilder, zobaczysz że ma ona dodatkowe parametry, które możesz przekazać. Wszystkie parametry trafią później do HealthCheckStatus – parametr w metodzie, w której tworzysz sprawdzenie – jak robiliśmy wyżej z ForecastServiceHealthCheck.
Dodatkowo możesz umieścić tam np. timeout. Mechanizm healthcheck mierzy czas wykonania każdego sprawdzenia. Jeśli przekażesz timeout i ten czas zostanie przekroczony, no to też dostaniesz odpowiednią informację.
Jeśli chodzi o listę tags, to możesz sobie wrzucić tam jakieś dodatkowe informacje, które są Ci potrzebne. O tym będzie jeszcze niżej.
Zabezpieczenie healthchecka – uwierzytelnianie
Zastanów się, czy każdy powinien mieć dostęp do Twojego healthchecka. Być może po drugiej stronie siedzi gdzieś ciemny typ, który próbuje hackować Twój system i zastanawia się jak po różnych krokach wygląda healthcheck. Jeśli dojdziesz do wniosku, że tylko niektóre osoby (maszyny) powinny mieć do tego dostęp, łatwo to ogarnąć.
W momencie, w którym mapujesz końcówkę healthchecka możesz dodać zabezpieczenia:
Po takiej konfiguracji, będzie można dobić się do healthchecka tylko z domeny localhost. Próba dojścia z innej da po prostu zwrotkę 404 Not Found. Możesz też pokombinować mocniej. Np. wymusić konkretny port z dowolnego hosta:
Takich metod Require* mamy kilka, których możemy używać do różnych ograniczeń.
RequireCors – będzie wymagało odpowiedniej polityki CORS. O CORSach pisałem tutaj,
RequireAuthorization – będzie wymagało uwierzytelnionego użytkownika. Jak to zrobisz, to już jest Twoja sprawa. W tej metodzie możesz podać politykę autoryzacyjną, możesz też role, schematy. Jeśli nie podasz niczego, będzie użyty domyślny schematy uwierzytelniania,
RequireRateLimiting – da Ci rate limiting na tej końcówce 🙂 Po krótce, jest to mechanizm, który pozwala uderzyć w dane miejsce nie częściej niż ileś tam razy. Czyli np. możesz sobie ustawić raz na minutę.
Te ograniczenia możesz ze sobą również łączyć. Nic nie stoi na przeszkodzie, żeby mógł dobić się tylko uwierzytelniony użytkownik z konkretnego hosta i to nie częściej niż co jakiś czas:
Z jakiegoś powodu możesz chcieć uruchamiać tylko niektóre sprawdzenia. Domyślny mechanizm uruchamia wszystkie zarejestrowane HealthChecki. Ale możesz stworzyć filtrować te serwisy i pozwalać na uruchamianie tylko niektórych. Ponadto, możesz mieć więcej końcówek dla różnych sprawdzeń. Na przykład:
app.MapHealthChecks("/_health", new HealthCheckOptions
{
ResponseWriter = UIResponseWriter.WriteHealthCheckUIResponse
});
app.MapHealthChecks("/_health_db", new HealthCheckOptions
{
Predicate = healthCheck => healthCheck.Tags.Contains("db")
});
Tutaj stworzyłem dwie końcówki:
_health – sprawdzi wszystkie zarejestrowane healthchecki i zwróci rezultat w JSON (tak jak pokazywałem wyżej)
_health_db – sprawdzi tylko te healthchecki, które zwróci Predicate – w tym wypadku te, które mają w swoich tagach słowo "db". I rezultat będzie zwrócony w standardowy sposób, czyli dostaniesz tylko informację Healthy lub Unhealthy (w tej końcówce nie posługujemy się ResponseWriterem).
A skąd ten filtr ma wiedzieć, że tag „db” oznacza bazę danych? Na szczęście to nie jest żadna magia i sam musisz zadbać o to, żeby do odpowiednich serwisów dodać odpowiednie tagi. Robisz to podczas ich rejestracji, np. tak:
//healthcheck
builder.Services.AddHealthChecks()
.AddDbContextCheck<AppDbContext>(tags: new string[] { "db" })
.AddCheck<ForecastServiceHealthCheck>("Forecast service");
Zwróć uwagę, jak w trzeciej linijce dodałem tagi do serwisu badającego bazę danych.
Dodanie endpointa do Swaggera
Skoro to czytasz, to zapewne zauważyłeś, że tak stworzony endpoint dla healthcheck nie jest dodawany do Swaggera. I przy obecnej technologii, gdzie możemy używać Postmana i requestów prosto z VisualStudio (plik *.http) nie widzę w tym większego sensu, ale się da. Wystarczy stworzyć i zarejestrować swój własny DocumentFilter.
IDocumentFilter to interfejs, który dostarcza informacji o dodatkowych operacjach. Standardowo Swagger szuka po prostu kontrolerów i akcji w nich i na tej podstawie (używając refleksji) tworzy swoją dokumentację. Oczywiście można mu dodać operacje, które nie są obsługiwane przez kontrolery. Wystarczy zaimplementować ten interfejs IDocumentFilter:
public class HealthCheckDocumentFilter : IDocumentFilter
{
public void Apply(OpenApiDocument swaggerDoc, DocumentFilterContext context)
{
var healthCheckOp = CreateHealthcheckOperation("_health", true);
var dbHealthCheckOp = CreateHealthcheckOperation("_health_db", false);
var healthPathItem = new OpenApiPathItem();
healthPathItem.AddOperation(OperationType.Get, healthCheckOp);
var dbHealthCheckPathItem = new OpenApiPathItem();
dbHealthCheckPathItem.AddOperation(OperationType.Get, dbHealthCheckOp);
swaggerDoc.Paths.Add("/_health", healthPathItem);
swaggerDoc.Paths.Add("/_health_db", dbHealthCheckPathItem);
}
private OpenApiOperation CreateHealthcheckOperation(string endpoint, bool returnsJson)
{
var result = new OpenApiOperation();
result.OperationId = $"{endpoint}OperationId";
var mediaType = returnsJson ? "application/json" : "text/plain";
var objType = returnsJson ? "object" : "string";
var schema = new OpenApiSchema
{
Type = objType
};
var response = new OpenApiResponse
{
Description = "Success"
};
response.Content.Add(mediaType, new OpenApiMediaType { Schema = schema });
result.Responses.Add("200", response);
return result;
}
}
No i musimy go zarejestrować podczas rejestracji Swaggera:
Nie będę omawiał tego kodu, bo nie ma nic wspólnego z healthcheckiem, tylko z dodawaniem operacji do Swaggera. Jest dość prosty i intuicyjny. Po prostu musimy dodać konkretne operacje (OpenApiOperation) do konkretnych endpointów (swaggerDoc.Paths.Add) i tyle. A każda operacja może składać się z różnych opisów, zwrotek itd. To wszystko co tutaj podasz, będzie potem widoczne w odpowiednich opisach na stronie Twojej dokumentacji.
To tyle na dzisiaj. Dzięki za przeczytanie tego artykułu. Jeśli czegoś nie rozumiesz lub znalazłeś jakiś błąd, koniecznie daj znać w komentarzu. Jeśli chciałbyś jakąś dodatkową wiedzę na temat healthchecków, to też daj znać. No i koniecznie podziel się tekstem z osobami, którym się przyda 🙂
Wraz z wersją ósmą .NET, o której pisałem w tym artykule, dostaliśmy też wersję 12 języka C#. Dzisiaj opiszę Ci wszystkie nowości i zmiany w tej wersji. Lecimy.
Główne konstruktory – Primary constructors
Do tej pory mogliśmy ich używać tylko w recordach. Od C#12 mamy je dostępne również w klasach i strukturach. Działają jednak troszkę inaczej. O co chodzi?
Spójrz na ten POPRAWNY w C#12 kod:
class Person(string name, int age)
{
public string Name { get; } = name;
public int Age { get; } = age;
}
Obok nazwy klasy znalazły się nawiasy z parametrami. To jest właśnie coś, co nazywamy primary constructor. Zwróć uwagę, że te parametry: name i age są dostępne w całym ciele klasy. Można je odczytywać, zmieniać i robić wszystko to, co robiłbyś z prywatnymi polami. No właśnie… prywatnymi. Nie możesz się do nich dobrać z zewnątrz, dlatego też powyżej widzisz utworzone właściwości, które zwracają ich wartości.
Tak samo to działa w strukturach. I to jest ta różnica między klasą/strukturą, a rekordem:
record MyRecord(int X, int Y)
{
public bool IsNegative()
{
return X < 0 || Y < 0
}
}
Jeśli używasz primary constructor w rekordach, kompilator automatycznie stworzy właściwości ( { get; init; } ) dla każdego takiego parametru. Dzięki czemu możesz się normalnie do nich odwoływać na rzecz obiektu.
Wróćmy jednak do naszej klasy:
class Person(string name, int age)
{
public string Name { get; } = name;
public int Age { get; } = age;
}
To, co tutaj widzisz to tak naprawdę cukier składniowy. Kompilator wygeneruje do tego kod, który będzie wyglądał mniej więcej tak:
class Person
{
private string __unspeakable_name;
private int __unspeakable_age;
public string Name => __unspeakable_name;
public Person(string name, int age)
{
__unspeakable_name = name;
__unspeakable_age = age;
}
}
Primary constructor z innymi konstruktorami
Jeśli chciałbyś mieć dodatkowe konstruktory, to musisz w nich wywołać ten primary constructor. Robi się to za pomocą słówka this:
class Person(string name, int age)
{
public string Name { get; } = name;
public Person(string name, DateTime birthday)
: this(name, DateTime.Now.Year - birthday.Year)
{
}
}
Dependency injection
Primary constructors wspierają również mechanizm dependency injection, co wydaje się całkiem interesującym rozwiązaniem. Prawdę mówiąc, to chyba jedyny powód, dla których chciałbym ich używać. No bo popatrz na standardowy kod:
class MyService
{
private readonly MyOtherService _service;
public MyService(MyOtherService service)
{
_service = service;
}
}
Używając primary constructors możemy go skrócić do takiego zapisu:
class MyService(MyOtherService service)
{
}
Jest kompresja.
Operacje na parametrach
No dobra, a jak poradzić sobie z sytuacją, gdzie w konstruktorze musimy zrobić jakieś sprawdzenia, czy coś w ten deseń? Czyli po staremu:
class Person
{
public Person(string name)
{
if (string.IsNullOrWhiteSpace(name))
throw new ArgumentException("Person must have a name");
}
}
Po prostu możemy użyć statycznej metody:
class Person(string name)
{
public string Name { get; } = ValidName(name) ? name : throw new ArgumentException("Person must have a name!");
private static bool ValidName(string name)
{
return !string.IsNullOrWhiteSpace(name);
}
}
Podczas tworzenia takiego obiektu, zostanie wywołana metoda ValidName. No i jeśli podamy niepoprawną wartość, wywali się. Czyli kod poniżej zadziała tak, jak się tego spodziewamy:
var person = new Person(""); //wywali się
Niemniej jednak nie podoba mi się to. Chociaż to pewnie głównie kwestia gustu. Natomiast uważam, że to czyni kod brzydkim, brudnym, a im więcej takich rzeczy, tym ciężej będzie się go debugować.
Tworzenie kolekcji – Collection expressions
Bardzo miłe ułatwienie. Do tej pory, żeby stworzyć tablicę, trzeba było napisać:
int[] tab = new int[] { 1, 2, 3 };
Stary, fajny, klasyczny kod. Collection expressions, które dostaliśmy w C#12 daje nam dużo prostszą i szybszą metodę:
int[] tab = [1, 2, 3];
Możemy to samo zrobić z listami, spanami i właściwie wszystkimi kolekcjami wspierającymi inicjalizatory:
List<int> list = [1, 2, 3];
IEnumerable<int> e = [1, 2, 3];
A teraz spójrz jeszcze na zaznaczoną powyżej linię. Widzisz, jak stworzyłem IEnumerable?
Ale jak to? Przecież IEnumerable to interfejs!
Azaliż. I tak naprawdę powstał obiekt klasy ReadOnlyArray<int>.
W taki sposób można tworzyć też wszystkie rodzaje tablic – wielowymiarowe, poszarpane (jagged arrays) itd.
Jak dla mnie, bardzo fajne rozwiązanie. Bardzo ułatwi pracę i zdecydowanie będę z niego korzystał.
Inline arrays
UWAGA! To jest dość zaawansowany temat. Jeśli nie bawiłeś się pamięcią i nie używałeś bibliotek z innych języków (np. C++, Pascal), prawdopodobnie ten akapit niczego Ci nie da.
Inline array to odpowiednio utworzona struktura. Jest odpowiednikiem fixed buffer w bezpiecznym kodzie (safe code). Spójrz w jaki sposób możesz utworzyć taką strukturę:
[InlineArray(3)]
struct InlineBuffer
{
public int element0;
}
Oznacza to, że tworzymy 3 elementową tablicę intów. Jedna rzecz jest istotna:
InlineBuffer buff = new InlineBuffer();
Teraz zmienna buff WSKAZUJE na pierwszy element tablicy – który jest jednocześnie polem element0. Czyli nie jest to referencja do tablicy, tylko sama tablica.
To jest przydatne, gdy walczymy bardzo o szybkość wykonywania kodu. Kompilator gwarantuje, że buff będzie po prostu ciągłą pamięcią o zadanej wielkości.
Ważne jest, że taka struktura nie może mieć żadnego layoutu i musi mieć jedno pole o typie, jakiego chcemy użyć w naszej tablicy.
Co istotne, to pole nie może być wskaźnikiem (w końcu to wskaźnik to niebezpieczny kontekst), ale może być każdym typem wartościowym i większością typów referencyjnych (w tym stringiem). A dobrać się możesz do konkretnych wartości tak samo jak w przypadku zwykłej tablicy – przez indekser. A także przez operator zakresu.
Domyślne parametry w wyrażeniach lambda
Nie ma się co rozpisywać. Po prostu w C#12 możemy używać domyślnych parametrów w wyrażeniach lambda. Wcześniej taki zapis w ogóle się nie kompilował. Obowiązują dokładnie te same reguły, co przy domyślnych parametrach metod:
var foo = (string s = "Siemma") => System.Console.WriteLine(s);
foo(); //wyświetli -> Siema
foo("Hej"); //wyświetli -> Hej
Modyfikator ref readonly
Do tej pory mieliśmy takie modyfikatory, którymi mogliśmy oznaczać parametry metody:
in
out
ref
W C#12 doszedł nowy: ref readonly.
W sumie, ref readonly robi dokładnie to samo, co in. Przyjrzałem się nawet kodowi generowanemu przez IL i te poniższe fragmenty C# tworzą dokładnie ten sam kod IL:
static void Main(string[] args)
{
int val = 10;
Show(val); //<-- pierwszy przypadek
Show2(ref val); //<-- drugi przypadek
Show2(in val); //<-- trzeci przypadek
}
public static void Show(in int value)
{
System.Console.WriteLine(value);
}
public static void Show2(ref readonly int value)
{
System.Console.WriteLine(value);
}
A kod IL też jest dość prosty, bo najpierw odkłada na stos ADRES zmiennej val, następnie wywołuje metodę, która ten adres ze stosu pobiera.
Jednak pewne, nieznaczne różnice są:
metoda przyjmująca parametr in nie potrzebuje, żeby kod wywołujący dawał o tym znać. Przy ref readonly bez jawnego określenia dostaniesz warning. Czyli:
//tu wszystko jest ok
Show(val);
public static void Show(in int value)
{
System.Console.WriteLine(value);
}
//tutaj dostaniesz warning, bo powinieneś wywołać metodę z modyfikatorem ref lub in (nie ma żadnego faktycznego znaczenia dla kodu):
Show(val); //<-- dostaniesz warning
//Show(ref val); //<-- bez warninga
//Show(in val); <-- bez warninga
public static void Show(ref readonly int value)
{
System.Console.WriteLine(value);
}
Zaznaczam – nie ma znaczenia, czy wywołasz metodę (ref readonly) z modyfikatorem ref, czy in. Kod w IL zostanie utworzony dokładnie ten sam.
jeśli przekażesz wartość (lub wyrażenie) do metody z modyfikatorem in, wszystko będzie ok; jeśli zrobisz to samo z metodą z modyfikatorem ref readonly – dostaniesz warning:
//tu wszystko jest ok
Show(10);
public static void Show(in int value)
{
System.Console.WriteLine(value);
}
//tutaj dostaniesz warning
Show(10); //<-- dostaniesz warning
public static void Show(ref readonly int value)
{
System.Console.WriteLine(value);
}
Jeśli jesteś ciekawy, co się wydarzy tutaj, to już mówię. Kompilator tak jakby stworzy za Ciebie zmienną, której przypisze wartość 10. Następnie adres tej zmiennej przekaże do metody.
Więc po co to ref readonly? Nie wiem. W specyfikacji czytam coś takiego:
W C# 7.2 wprowadzono parametry „in” jako sposób przekazywania referencji tylko do odczytu (w C++ nazywałoby się to stałą referencją – przyp. Adama). Parametry „in” dopuszczają zarówno lvalues jak i rvalues i można ich używać bez żadnej adnotacji podczas wywoływania.
Jednakże interfejsy API, które przechwytują lub zwracają referencje ze swoich parametrów chciałyby uniemożliwić rvalue a także wymusić pewne wskazanie w miejscu wywołania, że przechwytywana jest referencja.
Parametry ref readonly są idealne w takich przypadkach, ponieważ ostrzegają, jeśli zostaną użyte z rvalue lub bez żadnej adnotacji.
Także ma to na celu chyba tylko indykację, że metoda przyjmuje referencję.
Atrybut Experimental
C#12 daje nam nowy atrybut. System.Diagnostics.CodeAnalysis.ExperimentalAttribute. Możemy nim oznaczyć chyba wszystko. Od klasy, czy też enuma do pola, właściwości, czy zdarzenia.
Jeśli w kodzie użyjemy czegoś, co jest oznaczone atrybutem Experimental, kompilator wypluje ostrzeżenie, które zachowa się jak błąd. Trzeba jawnie oznaczyć to stłumić (suppress) to ostrzeżenie, żeby taki kod się zbudował.
Jeśli jednak wywołanie eksperymentalnego elementu będzie w innym eksperymentalnym elemencie, wtedy takie ostrzeżenie się nie pojawi. Czyli np.:
internal class MyClass
{
public static void Run()
{
Foo();
}
public static void Foo()
{
}
[Experimental("")]
public static void Bar()
{
}
}
Powyższy kod skompiluje się bez problemu. Poniższy też
public static void Run()
{
//Foo(); <-- wykomentowane wywołanie, czyli nie używamy metod eksperymentalnych
}
[Experimental("")]
public static void Foo()
{
Bar();
}
[Experimental("")]
public static void Bar()
{
}
Ale poniższy da już błąd:
public static void Run()
{
Foo(); //<-- użycie eksperymentalnej metody
}
[Experimental("")]
public static void Foo()
{
Bar();
}
Błąd mówi: Error CS9204 'Foo()' is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
Więc, jeśli chcemy jednak używać metody eksperymentalnej, musimy to ostrzeżenie będące błędem wyłączyć:
Można też zmniejszyć poziom tego ostrzeżenia – dokładnie tak samo jak innych. Możemy też to zrobić oczywiście globalnie, ale tego bardzo nie polecam.
Po co ten atrybut?
Raczej dla twórców bibliotek. Jeśli wprowadzają jakieś działanie, które w przyszłości może się mocno zmienić lub w ogóle zostać wywalone, wtedy oznaczenie tego jako Experimental jest dobrym pomysłem. A czy używanie takiego eksperymentalnego kodu jest dobrym pomysłem? Na produkcji raczej nie. W swoich wewnętrznych testach można się pobawić.
Wyłączanie ostrzeżeń o konkretnych funkcjonalnościach
Atrybut Experimental ma ciekawą właściwość. Można mu przekazać coś w rodzaju Id danej funkcjonalności (DiagnosticId), a potem tym Id posługiwać się podczas wyłączania ostrzeżenia. Np.:
Co więcej, możesz przekazać więcej informacji w komunikacie błędu – a konkretnie adres strony, na której jest opisana ta funkcjonalność lub powód dlaczego klienci nie powinni tego używać:
Error DoingFoo 'Foo()' is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed. (https://example.com/DoingFoo)
Interceptory
W chwili pisania tego artykułu (styczeń 2024) interceptory są eksperymentalne, więc póki co, nie opisuję ich. Ale będę trzymał rękę na pulsie i jeśli wejdą do użycia, na pewno o nich napiszę. Żeby tego nie przegapić, koniecznie zapisz się na newsletter 🙂
Dzięki za przeczytanie tego artykułu. Widać coraz bardziej, że C# idzie w stronę minimalizacji pisanego kodu, co jest z jednej strony fajnym rozwiązaniem. Chociaż może być cięższe do zrozumienia dla początkujących programistów. Niemniej jednak uważam, że to dobry krok naprzód. I choć w tej wersji może nie było jakiś super wielkich zmian, to jednak miło że MS słucha community.
Jeśli czegoś nie rozumiesz lub zauważyłeś w tekście jakiś błąd, daj znać w komentarzu 🙂
.NET8 wyszedł już oficjalnie jakiś czas temu. Przez ten czas sprawdzałem co i jak się zmieniło w tej ostatecznej wersji. Ale pracy przy tym było na tyle dużo, że w przyszłości jednak będę to robił na bieżąco w wersjach preview.
W tym artykule opisuję większość zmian i nowości, jakie zostały dla nas przygotowane. Elementy, które w pewnych okolicznościach mogą być lub są breaking changem, zaznaczyłem w kolorze czerwonym.
Weź pod uwagę, że to nie jest w 100% pełna lista. Wybrałem najciekawsze i najbardziej przydatne rzeczy wg mnie. Jeśli uważasz, że coś więcej powinno się znaleźć w tym artykule, daj znać w komentarzu.
Przede wszystkim, .NET8 w przeciwieństwie do siódemki jest oznaczony jako LTS (long-time-support). Co oznacza, że będzie oficjalnie wspierany przez 3 najbliższe lata. Więc jeśli tworzysz nowy system i wahasz się między wersją 7, a 8, to zdecydowanie powinieneś wybrać ósemkę, chociażby z tego względu.
Serializacja JSON
Doszło kilka nowości i usprawnień jeśli chodzi o serializację JSON:
dodano wsparcie dla dużych liczb: Int128 i UInt128 (a także dla Half – float16)
Tablice bajtów serializowane na Memory<byte> i ReadOnlyMemory<byte> domyślnie zmieniane są na Base64
JsonSerializer.Serialize(new byte[] { 1, 2, 3 }); // da w efekcie "AQID"
Deserializacja obiektu z brakującymi właściwościami
W .NET8 mamy teraz wybór, co zrobić gdy deserializujemy jsona do obiektu, który nie ma niektórych danych.
Załóżmy, że masz taką klasę:
internal class JsonData
{
public int Id { get; set; }
}
I takiego JSONa:
{
"Id": 42,
"AnotherId": -1
}
Po staremu, jeśli takiego jsona chciałeś deserializować do klasy JsonData, wszystko było ok. Po nowemu domyślnie też tak jest, a więc nie jest to żaden breaking change. Natomiast masz wybór, co zrobić w takiej sytuacji. Możesz się na to nie zgodzić, ustawiając odpowiedni atrybut na klasie:
[JsonUnmappedMemberHandling(JsonUnmappedMemberHandling.Disallow)]
internal class JsonData
{
public int Id { get; set; }
}
Teraz, JsonSerializer.Deserialize wywali się.
Serializacja enumów
Do tej pory mieliśmy dostępny specjalny konwerter JsonStringEnumConverter. Teraz mamy dostępną jego generyczną wersję JsonStringEnumConverter<T>. Ma to związek tylko z kompilacją AOT. Wersja generyczna nie wykorzystuje refleksji.
Nowe polityki nazw atrybutów
Do tej pory, parsując JSONa, mogliśmy używać polityki camelCase. Dawała ona tyle, że nazwa atrybutu w JSON mogła być napisana właśnie tak:
{
"nazwaMojegoPola": "wartość"
}
Oczywiście, była opcja żeby sobie dopisać własne polityki. Teraz jednak mamy dodatkowe, których możemy użyć: snake_case i kebab-case. Możemy to ustawić w opcjach serializacji dokładnie w taki sam sposób, jak ustawialiśmy camelCase.
Deserializacja pól tylko do odczytu
Załóżmy, że mamy taki model:
class Person
{
public int Id { get; set; }
public string Name { get; set; }
}
i prostą klasę, która go używa:
class Data
{
public Person Person { get; } = new();
}
Zauważ, że właściwość Person nie ma żadnego settera. W poprzednich wersjach .NET, taka deserializacja po prostu nie działała:
string json = "{\"Person\":{\"Id\": 5, \"Name\": \"Stefan\"}}";
Data d = JsonSerializer.Deserialize<Data>(json); //właściwość Person miała domyślne dane
Teraz, wystarczy że klasę Data opatrzysz odpowiednim atrybutem: [JsonObjectCreationHandling(JsonObjectCreationHandling.Populate)] i właściwość Person zostanie wypełniona odpowiednimi danymi.
Pamiętaj tylko, że klasa Person musi mieć przy swoich właściwościach settery.
Takie działanie możesz też ustawić globalnie w aplikacji:
Od .NET6 mamy możliwość (de)serializacji obiektów do JSON za pomocą wygenerowanego specjalnego kodu (kompilacja AOT), zamiast refleksji. Jest to szybsze (wg testów MS nawet 40%), jednak też ma minusy. Nie jest to artykuł o tym i jeśli nie robiłeś tego wcześniej, możesz pominąć ten fragment.
Przed .NET8 można było dodać własny JsonSerializationContext do opcji: JsonSerializerOptions.AddContext<TContext>. Teraz ta metoda jest oznaczona jako obsolete, ale mamy coś lepszego do dyspozycji. A mianowicie: TypeInfoResolverChain. Teraz można dodawać te konteksty swobodnie i swobodnie je usuwać:
Możliwość blokowania (de)serializacji opartej na refleksji
Możesz zablokować domyślną (de)serializację opartą na refleksji. Jeśli potrzebujesz zrobić bibliotekę AOT lub po prostu chcesz pokombinować z wydajnością. Wystarczy, że dodasz w pliku projektu odpowiedni wpis:
Potem, jeśli chcesz sprawdzić, czy refleksja jest dostępna, możesz posłużyć się właściwością JsonSerializer.IsReflectionEnabledByDefault
Używanie konstruktorów z parametrami
Domyślnie, JsonSerializer używa publicznego bezparametrowego konstruktora. Jednak możesz zmienić to zachowanie, używając odpowiedniego atrybutu:
public class MyClass
{
public int Data { get; private set; }
public MyClass()
{
}
public MyClass(string data)
{
Data = Convert.ToInt32(data);
}
[JsonConstructor]
internal MyClass(int data)
{
Data = data;
}
}
Zauważ, że w powyższym kodzie mamy 3 konstruktory. Jeden bez parametrów, drugi z jakimś parametrem string i trzeci, nie dość że oznaczony jako internal, to też z parametrem typu int.
Ze wszystkich konstruktorów możemy swobodnie korzystać. Dodatkowo JsonSerializer będzie korzystał tylko z konstruktora oznaczonego atrybutem JsonConstructor. Nie jest ważne, że jest to konstruktor wewnętrzny. JsonSerializer właśnie z niego skorzysta, przekazując w parametrze odpowiednią wartość.
UWAGA! W klasie możesz mieć tylko jeden konstruktor oznaczony tym atrybutem.
Jeśli chcesz zdeserializować jsona do takiego obiektu poza mechanizmem webowym (żądanie w kontrolerze), musisz stworzyć odpowiednie opcje:
string json = "{\"data\": 5}";
var options = new JsonSerializerOptions(JsonSerializerDefaults.Web);
var obj = JsonSerializer.Deserialize<MyClass>(json, options);
UWAGA! Ta forma deserializacji używa refleksji. Więc jeśli masz wyłączone używanie refleksji za pomocą np. właściwości JsonSerializerIsReflectionEnabledByDefault, wtedy przy próbie deserializacji dostaniesz błąd od Jsona.
Abstrakcje dla czasu
O, tego czasami brakowało i trzeba było samemu sobie robić takie abstrakcje, jeśli pewne rzeczy chciałeś mockować w testach jednostkowych. Teraz mamy to w standardzie.
W .NET8 powstała klasa abstrakcyjna TimeProvider, po której możemy dziedziczyć lub używać domyślnego, lokalnego czasu. Poniższy kod pokazuje te operacje:
internal class FakeTime : TimeProvider //tworzymy fake'ową klasę; można to też po prostu zamockować
{
public DateTimeOffset Now { get; set; }
public FakeTime(DateTimeOffset value)
{
Now = value;
}
public override DateTimeOffset GetUtcNow()
{
return Now;
}
}
internal class TimeProviderTest
{
public void Foo()
{
Bar(TimeProvider.System); //używamy domyślnej implementacji
TimeProvider fakeTime = new FakeTime(new DateTimeOffset(2000, 01, 01, 00, 00, 00, TimeSpan.Zero));
Bar(fakeTime); //używamy własnej implementacji
}
public void Bar(TimeProvider time)
{
Console.WriteLine("Aktualny czas: " + time.GetLocalNow()); //pobieramy czas z providera
}
}
Timer
Klasa TimerProvider daje nam też do dyspozycji całkiem fajny timerek. Możemy go utworzyć w taki sposób:
TimerCallback callback – delegat, który będzie cyklicznie uruchamiany. To po prostu metoda, która zwraca void i przyjmuje w parametrze nullable object: void Foo(object? state). Bardzo podobnie jak w ParametrizedThreadStart,
object? state – dane, które możemy przekazać do naszej metody. Jak widzisz, to może być dowolny obiekt,
TimeSpan dueTime – czas, jaki ma upłynąć od utworzenia timera, do pierwszego wywołania metody callback,
TimeSpan period – interwał uruchomienia metody callback. Czyli jeśli tu ustawimy np. 5 sekund, to metoda callback będzie wywoływana co 5 sekund.
ITimer ma też metodę Change, w której możesz zmienić interwał wywołań metody callback.
UWAGA! Timer różni się od tych, które możesz pamiętać z WinForms, czy starszych technologii. Ten timer wywołuje metodę callback na wątku branym z ThreadPoola. To oznacza, że metoda callback wywoływana jest na innym wątku. Pamiętaj o tym.
Co więcej, ITimer implementuje interfejs I(Async)Disposable. To znaczy, że musimy go zwalniać. Oczywiście tutaj zwykłe using ITimer... raczej nie wchodzi w grę, bo jest duża szansa, że timer zakończy swój żywot nim metoda callback się uruchomi.
Tak, jak inne tego typu timery, także ten ma ograniczony interwał, w którym może pracować. Ograniczenie jest spowodowane rozdzielczością zegara systemowego, którą możesz przyjąć na 15 milisekund. Jeśli podasz interwał mniejszy niż te 15 milisekund, to i tak, będzie pracował ze swoją minimalną.
Pomiar czasu między operacjami
TimeProvider umożliwia również mierzenie czasu między operacjami. Do tej pory mogliśmy stosować inne rozwiązania, np. Stopwatch. Tutaj mamy dokładnie to samo, tylko ładniej obudowane, spójrz na ten kod:
var start = TimeProvider.System.GetTimestamp();
Thread.Sleep(1025);
var elapsed = TimeProvider.System.GetElapsedTime(start);
System.Console.WriteLine("To trwało: " + elapsed);
//To trwało: 00:00:01.0326601
Metoda GetElapsedTime po prostu policzy różnicę między aktualnym Timestamp, a tym podanym. Jest jeszcze druga wersja, która liczy różnice pomiędzy dwoma timestampami.
Wywalenie ISystemClock
Wprowadzenie TimerProvider deaktualizuje interfejs ISystemClock, który być może ktoś z Was używał jako abstrakcję czasu. Jeśli tak, koniecznie zmień na TimerProvider.
Operacje losowe
Mamy kilka nowych metod, których możemy użyć do pracy z losowością.
GetItems<T>()
Metoda GetItems zwraca nam losowo wybrane elementy z jakiejś tablicy/listy/czegokolwiek. Spójrz na poniższy przykład, który mógłby zostać użyty do generowania haseł w systemie. Tylko dwie linijki:
Tablica chars zawiera wszystkie dostępne elementy, z których będziemy losować. Metoda GetItems losuje przekazaną ilość elementów (tutaj 10) z podanej tablicy wszystkich.
Oczywiście to nie ogranicza się do tablicy znaków. Możemy losować wszystko z każdej kolekcji (konwertując kolekcję na tablicę lub ReadOnlySpan).
Shuffle<T>()
Ta metoda, niby nowa, ale nie wymaga wyjaśniania. Jedna z moich ulubionych opcji w odtwarzaczu WinAmp 🙂 Metoda Shuffle, prawdopodobnie ze względu na optymalizację, miesza tylko w istniejącej tablicy / spanie. Tak więc jeśli masz listę, którą chcesz pomieszać, musisz ją najpierw przerzucić do tablicy. Dajmy trochę bardziej skomplikowany przykład – z listą obiektów, którą chcemy pomieszać:
class IdItem
{
public int Id { get; set; }
}
class RandomTestRunner
{
public static void Run()
{
List<IdItem> data = new();
for(int i = 1; i < 100; i++)
data.Add(new IdItem { Id = i });
var arr = data.ToArray();
Random.Shared.Shuffle(arr);
data = new(arr);
}
}
Najpierw tworzę sobie listę obiektów. Potem tworzę klasyczną tablicę z tej listy. Tablicę przekazuję do metody Shuffle. Ona tam sobie tą tablicę miesza. Na koniec tworzę listę z pomieszanej tablicy – obiekty są już w losowej kolejności.
Uważam że mimo swojej prostoty, te metody są całkiem fajne. Rzadko kiedy robię jakieś randomowe operacje, ale jak już robię, to musiałem takie rzeczy pisać sam. A teraz mamy gotowy mechanizm.
Nowe typy stworzone dla szybkości
.NET 8 wprowadził kilka typów, których zadaniem jest przyspieszenie niektórych operacji. Nie korzystałem z tego w rzeczywistych projektach, więc nie mogę powiedzieć, jak to faktycznie działa, ale postanowiłem zrobić mały benchmark. Zobaczmy po kolei.
System.Collections.Frozen
Ten namespace daje nam dwie nowe kolekcje – FrozenDictionary<TKey, TValue> i FrozenSet<T>. Są one tylko do odczytu. Jak już stworzysz, nie możesz niczego w nich zmienić. Teoretycznie zostały poczęte do tego, żeby operacje odczytu były szybsze niż w ich odpowiednikach. Sprawdźmy to.
Ring wolny
W lewym narożniku mamy klasyczne Dictionary<int, int>, a w prawym czeka FrozenDictionary<int, int>. Testy zostały przeprowadzone dla 12 przypadków. Różniły się:
ilość wpisów (1000, 10 000, 100 000, 1000 000)
ilość odczytów (1, 10, 100)
Kod, który był testowany wyglądał tak:
int result = 0;
for (int i = 0; i < Reads; i++)
result += dict[i];
return result;
Gdzie Reads to oczywiście ilość odczytów. Wyniki są jednoznaczne. Frozen wygrywa:
Method
ElementsCount
Reads
Mean
Ratio
RatioSD
ReadDictionary
1000
1
11.173 ns
1.00
0.00
ReadFrozen
1000
1
7.047 ns
0.64
0.11
ReadDictionary
1000
10
97.220 ns
1.00
0.00
ReadFrozen
1000
10
61.455 ns
0.64
0.08
ReadDictionary
1000
100
1,000.912 ns
1.00
0.00
ReadFrozen
1000
100
566.589 ns
0.57
0.07
ReadDictionary
10000
1
10.008 ns
1.00
0.00
ReadFrozen
10000
1
6.577 ns
0.70
0.08
ReadDictionary
10000
10
93.015 ns
1.00
0.00
ReadFrozen
10000
10
57.464 ns
0.62
0.05
ReadDictionary
10000
100
963.958 ns
1.00
0.00
ReadFrozen
10000
100
654.683 ns
0.69
0.11
ReadDictionary
100000
1
10.472 ns
1.00
0.00
ReadFrozen
100000
1
6.879 ns
0.67
0.12
ReadDictionary
100000
10
98.492 ns
1.00
0.00
ReadFrozen
100000
10
62.093 ns
0.64
0.09
ReadDictionary
100000
100
1,075.513 ns
1.00
0.00
ReadFrozen
100000
100
614.143 ns
0.58
0.09
ReadDictionary
1000000
1
10.387 ns
1.00
0.00
ReadFrozen
1000000
1
6.834 ns
0.66
0.08
ReadDictionary
1000000
10
89.935 ns
1.00
0.00
ReadFrozen
1000000
10
61.172 ns
0.69
0.06
ReadDictionary
1000000
100
1,013.573 ns
1.00
0.00
ReadFrozen
1000000
100
620.679 ns
0.62
0.08
System.Buffer.SearchValues<T>
SearchValues to swego rodzaju tablica. Używamy jej, gdy często szukamy jakiś wartości. Np. jeśli często byśmy szukali samogłosek w stringach, można by było napisać taki kod:
string str = "To jest jakiś tekst napisany przez Adama"; //tekst, w którym będziemy szukali
string chars = "aeiou"; //samogłoski, których szukamy
ReadOnlySpan<char> needles = new ReadOnlySpan<char>(chars.ToArray()); //teraz musimy skonstruować Span
SearchValues<char> values = SearchValues.Create(needles); //to przyjmuje tylko ReadOnlySpan
var result = str.AsSpan().IndexOfAny(values); //no i szukamy
SearchValues niestety może być utworzone jedynie z ReadOnlySpan byte'ów lub char'ów.
Generalnie powstało to po to, żeby optymalizować częste szukanie pewnych danych. Wszelkie optymalizacje są robione w momencie wywołania SearchValues.Create <– to tutaj dzieje się cała magia. Dlatego pamiętaj, że żeby to miało sens, metoda Create powinna być użyta tylko raz, a Twoje SearchValues powinno żyć tak długo, jak długo z niego korzystasz.
To ma być w przyszłości używane również przez operacje Regex, które dzięki temu mogą stać się szybsze. Z tego, co wiem, na moment pisania tego artykułu w .NET8 to jeszcze nie jest ogarnięte.
A teraz sprawdźmy przykładowy program. Sprawdzanie, czy string zawiera jedynie duże i małe litery bez znaków specjalnych. Sprawdzimy trzy metody:
[MemoryDiagnoser]
public class BufferTestBenchmark
{
private static SearchValues<char> _searchValues;
private string _allowedChars = "qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM";
[Params("qoiudhjkfdsbnfmaQOIUDHJKFDSBNFMA", "qoiudhjkfdsbnfm@QOIUDHJKFDSBNFM@", "@oiudhjkfdsbnfma@OIUDHJKFDSBNFMA")]
public string Value { get; set; }
public BufferTestBenchmark()
{
_searchValues = SearchValues.Create(_allowedChars.AsSpan());
}
[Benchmark(Baseline = true)]
public bool UsingSearchValues()
{
return !Value.AsSpan().ContainsAnyExcept(_searchValues);
}
[Benchmark]
public bool UsingContains()
{
foreach(var ch in Value)
{
if (!_allowedChars.Contains(ch))
return false;
}
return true;
}
[Benchmark]
public bool UsingSpan()
{
return !Value.AsSpan().ContainsAnyExcept(_allowedChars);
}
}
Czyli mamy string, który na początku ma specjalny znak, na końcu i tak, który nie ma go w ogóle (czyli jest zgodny z założeniami). Wyniki wyglądają następująco:
Method
Value
Mean
Ratio
RatioSD
UsingSearchValues
@oiud(…)BNFMA [32]
8.984 ns
1.00
0.00
UsingContains
@oiud(…)BNFMA [32]
7.922 ns
0.89
0.14
UsingSpan
@oiud(…)BNFMA [32]
116.279 ns
13.13
1.58
UsingSearchValues
qoiud(…)BNFM@ [32]
9.134 ns
1.00
0.00
UsingContains
qoiud(…)BNFM@ [32]
90.065 ns
10.12
1.76
UsingSpan
qoiud(…)BNFM@ [32]
119.263 ns
13.39
2.25
UsingSearchValues
qoiud(…)BNFMA [32]
6.140 ns
1.00
0.00
UsingContains
qoiud(…)BNFMA [32]
203.261 ns
33.54
4.97
UsingSpan
qoiud(…)BNFMA [32]
114.471 ns
18.97
2.55
Jak widać, w większości użycie SearchValues daje ogromne różnice na plus. Zatem jednoznacznie wychodzi, że jeśli robimy jakieś częste przeszukiwania konkretnych elementów, zdecydowanie warto zastanowić się nad SearchValues.
Formatowanie stringów – CompositeFormat
Ok, ogólnie rzecz biorąc mamy do dyspozycji trzy metody formatowania stringów (nie licząc niektórych przeciążeń metod w stylu Console.Write, które i tak sprowadzają się do użycia string.Format). A są to:
string.Format, który jest od początku
interpolacja stringów
i nowość – klasa CompositeFormat
Czy to nie jest jakaś klęska urodzaju? Nie.
Na początku był string.Format. Ogarniał wszystkie możliwe przypadki. Potem, wiele lat później doszły interpolowane stringi, czyli coś takiego:
int i = 10;
string s = $"Cześć, jestem interpolowanym stringiem. Wartość zmiennej to: {i}";
Początkowo interpolowane stringi pod spodem sprowadzały się do wykonania string.Format. Później jednak były w jakiś sposób optymalizowane. A i ich zapis wydaje się bardziej czysty.
Ale co zrobić w momencie, gdy nie znasz formatu stringa w czasie pisania apki? Na przykład ten format przychodzi z zasobów albo z innego miejsca?:
int data = 10;
string format = _resourceProvider.GetFormatForString();
string result = string.Format(format, data);
Wciąż musimy używać string.Format. Najczęściej taka sytuacja będzie związana pewnie z pobieraniem stringów z tłumaczeń.
Problem leży w tym, że takie rozwiązanie nie jest idealne. Na pewno można szybciej to rozwiązać… No i w .NET8 zrobili nam klasę CompositeFormat. Ta klasa w pewien sposób kompiluje sobie format, który ma użyć. I robi to tylko raz. String.Format robił coś takiego przy każdym użyciu. Dzięki czemu CompositeFormat wydaje się być bardziej wydajne… Sprawdźmy to.
Testujemy prędkość
Kod, który testuję wygląda tak:
[MemoryDiagnoser]
public class StringFormatBenchmark
{
private static string format = "Hello {0}, today is {1}";
private static readonly CompositeFormat s_cFormat = CompositeFormat.Parse(format);
[Benchmark(Baseline = true)]
public string FormatTest()
{
string result = string.Format(format, "Adam", DateTime.Now);
return result;
}
[Benchmark]
public string CompositeFormatTest()
{
string result = string.Format(null, s_cFormat, "Adam", DateTime.Now);
return result;
}
[Benchmark]
public string InterpolatedTest()
{
string result = $"Hello {"Adam"}, today is {DateTime.Now}";
return result;
}
}
Jak widać, użycie CompositeFormat jest szalenie proste. Grunt, żeby to było utworzone tylko raz. A potem i tak wykorzystujemy odpowiednie przeciążenie string.Format.
Wersję ze stringiem interpolowanym dodałem tylko ze względu na dopełnienie obrazu. Pamiętaj, że jednak chodzi o dwa różne scenariusze – interpolowane stringi zawsze znają format. String.Format dostaje go w trakcie trwania aplikacji. Spójrzmy na wyniki:
Method
Mean
Error
StdDev
Ratio
RatioSD
Gen0
Allocated
Alloc Ratio
FormatTest
494.9 ns
10.67 ns
28.84 ns
1.00
0.00
0.0801
128 B
1.00
CompositeFormatTest
468.4 ns
10.04 ns
27.66 ns
0.95
0.07
0.0658
104 B
0.81
InterpolatedTest
458.3 ns
13.24 ns
37.78 ns
0.93
0.09
0.0658
104 B
0.81
Tutaj widać, że string.Format i CompositeFormat mają bardzo podobny czas. CompositeFormat jest nieco szybszy, ale czy to będzie zauważalne w prawdziwej apce? Ciężko powiedzieć. Jeśli jednak ktoś zapytałby się mnie, czy warto zmieniać klasyczny string.Format na CompositeFormat, to zdecydowanie powiedziałbym, że nie. Jeśli jednak piszesz nową apkę, przemyśl to, bo w kolejnych wersjach CompositeFormat może dostać większego kopa.
Walidacja danych
W .NET8 mamy kilka nowych atrybutów DataAnnotations. Nie będę ich dokładnie opisywał, bo ich użycie jest dokładnie takie samo lub analogiczne. Po prostu wiedz, że zostały dodane:
RangeAttribute
RangeAttribute.MinimumIsExclusive – określa, czy wartość minimalna w [Range] jest otwarta (true), czy zamknięta. Innymi słowy, czy ta wartość ma się zawierać w zakresie,
RangeAttribute.MaximumIsExclusive – analogicznie jak wyżej, tylko dotyczy to maksymalnej wartości. Np.:
public class Model
{
[Range(18, 30, MinimumIsExclusive = true, MaximumIsExclusive = false)]
public int Age { get; set; }
}
Oznacza, że Age powinien być w zakresie (18, 30>, czyli 18 nie spełnia wymagań (MinimumIsExclusive). Czyli mamy tutaj od 19 do 30 włącznie (MaximumIsExclusive = false).
LengthAttribute
Dodano drugą wartość – maksymalną. Dzięki temu można ustawić walidację na stringa (lub kolekcję), która sprawdzi, czy string ma między min i maks znaków. Np.:
public class Model
{
[Length(3, 12)]
public string Name { get; set; }
}
Teraz Name powinno mieć między 3 i 12 znaków włącznie (3 też będzie ok).
Base64Attribute
O, to jest dość fajne. Sprawdza, czy string jest prawidłowym stringiem w formacie Base64:
public class Model
{
[Base64String]
public string Data { get; set; }
}
AllowedValuesAttribute i DeniedValuesAttribute
One sprawdzają, czy przekazany string znajduje się na liście zezwolonych lub zabronionych stringów:
public class Model
{
[AllowedValues("mama", "tata", "koń")]
[DeniedValues("koza")]
public string Data { get; set; }
}
Niestety te atrybuty działają tylko na stringach. Nie działają na kolekcjach ani na obiektach innych klas pomimo, że w konstruktorze przyjmują tablicę object.
Zipowanie do strumienia
Dostaliśmy nowe operacje zipowania, dzięki którym możemy pakować wszystkie pliki, znajdujące się w konkretnym katalogu, do strumienia.
using (var stream = new MemoryStream())
{
ZipFile.CreateFromDirectory("dataToZip", stream, CompressionLevel.SmallestSize, false);
}
Te przeciążenia powstały właśnie do tego, żeby nie robić operacji na plikach. Żeby bez sensu nie obciążać dysków, jeśli nie trzeba.
Dodatki w Dependency Injection
Chłopaki w .NET8 wprowadzili KeyedServices. Polega to na tym, że możesz zarejestrować w dependency injection różne serwisy pod różnymi indeksami dla jednego interfejsu.
Załóżmy, że mamy interfejs ISomeService:
public interface ISomeService
{
void Foo();
}
I teraz chcesz zarejestrować dwa różne serwisy dla tego interfejsu w dwóch „pulach”. Tak to by chyba można było nazwać. Spójrz na rejestrację:
Tutaj są zarejestrowane dwa serwisy pod różnymi kluczami (user i admin). Jednak to prowadzi do pewnego problemu. Jak je pobrać? Tak nie da rady:
public SomeController(ISomeService someService)
{
_someService = someService;
}
Apka się po prostu wywali. Musimy jasno określić, z którego klucza chcemy pobrać dany serwis. Służy do tego odpowiedni atrybut:
public SomeController([FromKeyedServices("user")]ISomeService someService)
{
_someService = someService;
}
Można to zrobić też bardziej dynamicznie. Najprostszy mechanizm, który tworzyłby odpowiedni serwis w zależności od zalogowanego użytkownika mógłby wyglądać tak:
public class SomeController
{
[HttpGet]
public IActionResult Get()
{
bool loggedIsAdmin = User.HasClaim("admin", "true");
string key = loggedIsAdmin ? "admin" : "user";
ISomeService service = HttpContext.RequestServices.GetRequiredKeyedService<ISomeService>(key);
service.Foo();
return Ok();
}
}
Oczywiście tutaj musimy pobierać serwis ręcznie. Nie da się wstrzyknąć do konstruktora serwisu w zależności od zalogowanego użytkownika. Przynajmniej nie w standardzie.
Oczywiście zawsze można sobie wstrzyknąć IServiceProvider, jednak jeśli to jest robione poza jakąś fabryką, to wtedy raczej będzie złym rozwiązaniem, które nam zrobi Abstract Service Locatora.
Dodatki do IHostedService, czyli większa kontrola nad cyklem życia
O interfejsie IHostedService i po co to jest pisałem w tym artykule – jak korzystać z dobrodziejstw Dependency Injection i tych wszystkich mechanizmów w aplikacji konsolowej (i nie tylko).
Natomiast w .NET8 doszedł nowy interfejs IHostedLifecycleService. On implementuje już znany nam IHostedService, dodając kilka metod, dzięki którym masz większą kontrolę nad cyklem życia Twojej aplikacji.
Więc albo implementujesz IHostedService do swojego hosta i nic się dla Ciebie nie zmienia, albo implementujesz IHostedLifecycleService i dostajesz dodatkową kontrolę nad cyklem życia. A metody wywoływane są w takiej kolejności:
IHostLifetime.WaitForStartAsync
IHostedLifecycleService.StartingAsync
IHostedService.Start
IHostedLifecycleService.StartedAsync
IHostApplicationLifetime.ApplicationStarted
IHostedLifecycleService.StoppingAsync
IHostApplicationLifetime.ApplicationStopping
IHostedService.Stop
IHostedLifecycleService.StoppedAsync
IHostApplicationLifetime.ApplicationStopped
IHostLifetime.StopAsync
Zmiany w konfiguracji aplikacji
Walidacja opcji bez użycia refleksji
O walidacji opcji pisałem już w tym artykule. Natomiast w .NET8 wszedł mechanizm, który możemy używać w kompilacjach AOT – nie używa refleksji. Załóżmy, że model, który chcesz walidować wygląda tak:
public class MyAppConfig
{
[EmailAddress]
[Required]
public string SmtpAdress { get; set; }
[Range(1, 10)]
public int TraceLevel { get; set; }
}
Aby teraz mieć walidację zgodną z AOT, musisz…. poniekąd sam ją napisać. Ale sprowadza się to jedynie do utworzenia pustej klasy:
[OptionsValidator]
public partial class MyAppConfigValidator: IValidateOptions<MyAppConfig>
{
}
I to jest dokładnie tyle. Dobrze widzisz. Tutaj są istotne dwie rzeczy:
klasa musi być oznaczona jako partial
klasa musi posiadać atrybut [OptionsValidator]
W innym wypadku po prostu się nawet nie skompiluje. Na koniec musimy ją jeszcze zarejestrować:
W efekcie zostanie wygenerowany kod dla klasy MyAppConfigValidator, który będzie miał zaszytą całą logikę walidacji w sobie. I to wszystko zadzieje się bez wykorzystania refleksji. Dzięki temu możesz tego używać w kompilacjach AOT.
Bindowanie opcji bez użycia refleksji
Jeśli chodzi o rejestracje opcji, tj. Configure(TOptions), Bind i Get, to standardowo była do tego wykorzystywana refleksja. W .NET8 w aplikacjach internetowych domyślnie konfiguracja jest realizowana przez generator kodu. Czyli jest to zgodne z AOT i nie wymaga żadnych zmian.
Jeśli jednak chcesz być zgodny z AOT i nie tworzysz aplikacji webowej, musisz na takie działanie jawnie wyrazić zgodę. Wystarczy dodać ustawienie w projekcie:
Tak! Dorzucili coś do WPFa 🙂 A konkretnie dwie rzeczy.
Przyspieszenie sprzętowe dla RDP
Mniej interesująca dla mnie jest taka, że aplikacje WPF dostępne zdalnie (za pomocą zdalnego pulpitu – RDP) używały softwarowego przyspieszenia graficznego. Teraz mogą używać hardwareowego, czyli są wspomagane kartą graficzną. Musisz jednak na to wyrazić zgodę. Trzeba w pliku runtimeconfig.json wpisać ustawienie Switch.System.Windows.Media.EnableHardwareAccelerationInRdp z wartością true.
Kontrolka do wyboru folderu
Wreszcie! Po tyyylu latach. Już nie trzeba używać third parties albo kontrolki z Win32, żeby dać użytkownikowi możliwość wyboru folderu. Trochę śmieje się przez łzy, że ktoś to wreszcie ogarnął 😀 W .NET8 możemy już wykorzystywać pełnoprawne okienko WPF:
var openFolderDialog = new OpenFolderDialog()
{
Title = "Wybierz folder...",
InitialDirectory = Environment.GetFolderPath(
Environment.SpecialFolder.ProgramFiles)
};
string folderName = "";
if (openFolderDialog.ShowDialog())
{
folderName = openFolderDialog.FolderName;
}
Typowe breaking change
MinimalApi i IFormFile
W .NET8, jeśli w MinimalAPI używasz IFormFile lub IFormFileCollection, teraz będzie wymagane posiadanie antiforgery token. I tak jest domyślnie. Jeśli chcesz z tego zrezygnować (zastanów się, czy na pewno powinieneś), możesz to zrobić w konfiguracji endpointa:
Jeśli posługujesz się zdarzeniami OpenIdConnect (np. OnTokenValidated), to w kontekście takiego zdarzenia jest do dyspozycji SecurityToken. SecurityToken to klasa abstrakcyjna. Wcześniej w tym kontekście była reprezentowana przez JwtSecurityToken, więc jeśli rzutujesz ten token na tą klasę, to Ci wszystko wybuchnie. Teraz JwtSecurityToken zostało wymienione na JsonWebToken.
Usunięte mapowanie separatora ścieżki dla systemów Unixowych
Do tej pory, jeśli podawałeś jakąś ścieżkę, np.:
var fileName = @"path\to\file\file.jpg"
na systemach unixowych separatory ścieżki (backslash) były zamieniane na slashe. Czyli to \ na to /. Od werji .NET8 tego nie ma. Usunięcie tego mapowania ma związek z różnymi problemami z uruchomieniem aplikacji, które się zdarzały. Jak sobie z tym poradzić?
nie hardkoduj znaków separatora ścieżki. Zamiast tego używaj zmiennej Path.DirectorySeparatorChar,
jeśli na systemach unixowych wywołujesz polecenie dotnet, przekazując mu jakieś ścieżki, upewnij się że to są slashe (/), a nie backslashe(\),
na systemach unixowych zaktualizuj wszystkie zmienne środowiskowe, które zawierają ścieżki – właśnie w taki sposób, żeby backslashe zamienić na slashe.
Rzucanie wyjątku przy próbie zapisu do zamkniętego pliku
Wcześniej, jeśli próbowałeś zapisać coś do zamkniętego pliku (za pomocą FileStream), był rzucany wewnętrzny wyjątek, jednak był on zupełnie ignorowany. Nic się w pliku nie zapisywało, a rezultat operacji wskazywał na powodzenie. Czyli „operacja się udałą, pacjent umarł”.
Teraz, w .NET8, próba takiego zapisu zakończy się rzuceniem wyjątku IOException. Miej to na uwadze.
Konwersja DMTF na DateTime
Do tej pory metoda ManagementDateTimeConverter.ToDateTime(String) zwracała obiekt DateTime z DateTime.Kind ustawionym na wartość Unspecified. Teraz ta wartość jest ustawiona na Local. Więc jeśli na niej polegałeś, koniecznie sprawdź swój kod.
Inne zmiany
W .NET8 wprowadzono też szereg zmian, o których nie piszę w tym artykule z różnych powodów. Niemniej jednak chcę dać Ci szybki dostęp do nich, więc wrzucam interesuące linki:
Breaking changes w .EFCore
Możesz spotkać problemy w starszych serwerach SQL od wersji 2014 w dół (razem z 2014). Co więcej, jeśli używasz JsonDocumentów, to zmienili sposób serializacji enumów. Teraz domyślnie idą intami. Wprowadzono też zmiany w SQLite, CosmosDB i mniejsze.
Mimo wszystko polecam zapoznać się z tym krótki artykułem, być może rozwiąże to Twoje problemy szybciej niż Stack Overflow 🙂
Zmiany w Blazor, SignalR, MinimalApis, NativeAOT, Kestrel, Identity
Jest jeszcze kilka fajnych zmian w Blazor. Ale to jest kwestia na zupełnie inny artykuł, więc odsyłam Cię po prostu do źródła.
Ciekawą zmianę dodali też w .NET Identity (o ile możemy to tak jeszcze nazywać). Wprowadzili m.in. endpointy do logowania, wylogowania, pobierania info o użytkowniku itp. Tak out of the box. Ale dla użycia tylko w apkach webowych (nie nadaje się raczej do WebApi).
Ufff, to tyle. Dzięki za przeczytanie tego artykułu. Mam głęboką nadzieję, że będzie naprawdę pomocny. A dla Ciebie jakie zmiany były najważniejsze? Daj znać w komentarzu.
Dla wielu programistów, interfejs IEnumerable to po prostu interfejs implementujący jakąś metodę GetEnumerator. Ale kryje się pod nim sporo więcej. W tym artykule postaram się opisać jak dokładnie działa IEnumerable, czym jest enumerator i iterator. Kilka rzeczy sprawdziłem też w kodzie IL (intermediate language), żebyś Ty już nie musiał 😀
Po co nam IEnumerable?
Zacznijmy od początku. IEnumerable jest nam potrzebne, żebyśmy mogli:
stosować pętlę foreach
stosować zapytania LINQ
W jaki sposób to działa? IEnumerable zwraca enumerator. Czyli obiekt, który potrafi przeiterować się po jakiejś kolekcji.
Czym jest enumerator?
Enumerator to, krótko mówiąc, klasa, która posiada dostęp do jakiejś kolekcji danych (np. w postaci tablicy) i potrafi po tych danych przejść od początku do końca. Enumerator musi zatem mieć następujące metody:
MoveNext() – ustawia się na następnym elemencie w kolekcji
Reset() – resetuje „licznik” – czyli przechodzi na początek kolekcji
a także właściwość Current, która zwraca aktualnie WSKAZYWANY element. Najprostszy enumerator mógłby wyglądać tak:
class SimpleEnumerator : IEnumerator
{
private readonly int[] _data;
private int _index;
public object Current
{
get
{
if (_index < 0 || _index >= _data.Length)
throw new IndexOutOfRangeException();
return _data[_index];
}
}
public SimpleEnumerator(int[] data)
{
_data = data;
Reset();
}
public bool MoveNext()
{
_index++;
return _index < _data.Length;
}
public void Reset()
{
_index = -1;
}
}
Kod jest na tyle prosty, że nie wymaga za bardzo omówienia. Właściwość Current, a także metody MoveNext i Reset pochodzą z interfejsu IEnumerator.
To co Cię może zadziwić na pierwszy rzut oka, to to że metoda Reset ustawia licznik na -1, zamiast na zero. Ale to jest dobra praktyka i tego się powinniśmy trzymać. Dlaczego? Bo z enumeratorem pracuje się tak:
int[] data = new int[] { 1, 2, 3, 4, 5 };
SimpleEnumerator enumerator = new SimpleEnumerator(data);
while(enumerator.MoveNext())
{
Console.WriteLine(enumerator.Current);
}
Naturalnym dla niego jest właśnie iteracja za pomocą pętli while. Metoda MoveNext zwraca true, jeśli jesteśmy ustawieni na faktycznym elemencie lub false, jeśli jesteśmy już poza elementem (indeks jest poza zakresem). Dzięki temu pętla while wie, kiedy się zakończyć.
Teraz zwróć uwagę, że gdyby metoda Reset ustawiała index na 0, wtedy nigdy przy takim kodzie nie otrzymamy pierwszego elementu.
Generyczny Enumerator
Jak już pewnie zauważyłeś, ten podstawowy IEnumerator operuje na typie object. Dlatego też powstał enumerator generyczny, który może pracować z każdym typem: IEnumerator<T>. W związku z tym, że to może być dowolny typ, IEnumerator<T>, poza interfejsem IEnumerator, implementuje także interfejs IDisposable. Więc nasz enumerator teraz mógłby wyglądać tak:
class IntEnumerator : IEnumerator<int>
{
private bool disposedValue;
private readonly int[] _data;
private int _index;
public IntEnumerator(int[] data)
{
_data = data;
Reset();
}
public int Current
{
get
{
if (_index < 0 || _index >= _data.Length)
throw new IndexOutOfRangeException();
return _data[_index];
}
}
object IEnumerator.Current => Current;
public bool MoveNext()
{
_index++;
return _index < _data.Length;
}
public void Reset()
{
_index = -1;
}
//dalej jest standardowa implementacja IDisposable
}
Używamy go dokładnie tak samo jak tego niegenerycznego.
Ok, ja Ci tu gadam o enumeratorach, a jak to się właściwie ma do tego foreach, o którym pisałem na początku?
Jeśli w powyższym przypadku zamiast tablicy, użyjemy listy (albo innej kolekcji – byle nie tablicy) i zrobimy coś takiego:
static void Main(string[] args)
{
int[] data = new int[] { 1, 2, 3, 4, 5 };
List<int> list = new List<int>(data);
foreach(var i in list)
{
Console.WriteLine(i);
}
}
to kod, jaki zostanie wygenerowany przez kompilator w (IL – intermediate language) będzie wyglądał po przetłumaczeniu na „ludzki” tak (instrukcje w stylu goto zamieniłem na pętlę):
IEnumerator<int> enumerator = list.GetEnumerator();
while(enumerator.MoveNext())
{
int value = enumerator.Current;
Console.WriteLine(value);
}
Co z tego wynika? Jeśli posługujemy się pętlą foreach w naszym programie, to ostatecznie wyjdzie z tego pętla, która posługuje się enumeratorem.
Trochę inaczej to wygląda, gdy zamiast listy damy zwykłą tablicę. Wtedy wygenerowany kod będzie zoptymalizowany w taki sposób, że nie będzie posługiwał się enumeratorem.
To teraz pytanie, co z tym GetEnumerator?
GetEnumerator
Jak już wiesz, GetEnumerator pochodzi z interfejsu IEnumerable. Czyli IEnumerable jest niejako takim pudełkiem na enumerator. Jednakże IEnumerable jest tylko dla naszej wygody, ponieważ foreach możesz zrobić po JAKIEJKOLWIEK klasie, która posiada metodę GetEnumerator i zwraca w niej IEnumerator, na przykład – po takiej:
class MyIntData
{
private int[] _data;
public MyIntData(int[] data)
{
_data = data;
}
public IEnumerator<int> GetEnumerator()
{
return new IntEnumerator(_data);
}
}
Zobacz, że klasa MyIntData nie implementuje interfejsu IEnumerable, ale posiada metodę GetEnumerator, w której zwraca enumeratora stworzonego wcześniej w tym artykule:
int[] data = new int[] { 1, 2, 3, 4, 5 };
MyIntData myInts = new MyIntData(data);
foreach(var i in myInts)
{
Console.WriteLine(i);
}
Kod wygenerowany przez kompilator będzie dokładnie taki sam (jeśli chodzi o pętlę foreach), jak w przypadku poprzedniego listingu.
Oczywiście tworzenie klasy w taki sposób jest trochę wbrew intuicji i dobrym praktykom. Taka klasa powinna jednak implementować IEnumerable lub jego generyczną wersję. Co by nie mówić, wiele klas w .NET i w innych bibliotekach spodziewa się właśnie interfejsu IEnumerable w swoich metodach.
Zazwyczaj nie powinieneś też musieć tworzyć własnego enumeratora. Jeśli jednak z jakiegoś powodu musisz, jest prostsza metoda…
Czym jest iterator?
Mógłbym powiedzieć, że iterator to w C# cukier składniowy. Spójrz na nieco zmieniony kod naszej klasy:
class MyIntData
{
private int[] _data;
public MyIntData(int[] data)
{
_data = data;
}
public IEnumerator<int> GetEnumerator()
{
for(int i = 0; i < _data.Length; i++)
yield return _data[i];
}
}
Kompilator trafiając na taki kod, stworzy wewnętrzną klasę dla takiego enumeratora. Wewnętrzną w sensie zagnieżdżoną w MyIntData. Wyposaży ją we wszystkie potrzebne rzeczy, jednak metoda Reset() rzuca wyjątek NotSupportedException.
Generalnie to będzie nieco inny enumerator niż ten, co stworzyliśmy sami. Działa na zasadzie maszyny stanów. Kod nieco bardziej skomplikowany (od strony IL), ale też bez przesady.
Co to jest to yield?
Zapamiętaj, że w C# samo yield nie istnieje. Patrząc wysokopoziomowo, mamy yield return, które zwraca element kolekcji, a potem wraca do tego samego momentu, a także opcjonalne yield break, żeby zaznaczyć, że nie ma już więcej elementów.
W tym momencie powinieneś już wiedzieć, jaka jest rola enumeratora, iteratora i interfejsu IEnumerable. Ale są jeszcze dwie rzeczy o IEnumerable, o których powinieneś wiedzieć…
IEnumerable nie daje wyników od razu
Innymi słowy – jest odroczone (deferred). Niejednemu programiście (a i mi osobiście też) spędziło to sen z powiek. Spójrz na ten kod:
List<int> list = new List<int> { 1, 2, 3};
var lessThan3 = list.Where(x => x < 3);
list.Add(0);
foreach(var x in lessThan3)
{
Console.WriteLine(x);
}
Najpierw tworzymy jakąś listę z cyframi 1, 2 i 3. Następnie pobieramy sobie do jakiejś zmiennej cyfry mniejsze od 3 – czyli 1 i 2. Na koniec dodajemy do głównej listy cyfrę 0.
Jaki będzie wynik?
UWAGA! Analogiczne zadanie pojawia się na rozmowach o pracę 🙂
Konsola wypisze: 1, 2, 0.
Dlaczego to zero, skoro pobraliśmy cyfry mniejsze od 3, gdy nie było zera na liście? Odpowiedź jest prosta – nie pobraliśmy.
IEnumerable ma tzw. odroczone wykonanie (deferred execution). To oznacza, że enumerator zostanie uruchomiony dopiero wtedy, kiedy potrzebujemy konkretnych danych. W tym kodzie powyżej tych danych potrzebujemy dopiero w pętli foreach. Ale jeśli byśmy zrobili tak:
var lessThan3 = list.Where(x => x < 3).ToList();
czyli na koniec warunku zmieniamy wszystko na listę, to wtedy odczytujemy te dane od razu – potrzebujemy ich w tym momencie. Już w tym momencie enumerator jest uruchamiany.
Dlaczego tak jest? To jest czysta optymalizacja. Weź pod uwagę taki przykładowy kod:
List<int> list = new List<int> { 1, 2, 3};
var data = list.Where(x => x < 3);
data = data.Where(x => x % 2 == 0);
data = data.Select(x => x + 1);
Tutaj iterator nie ruszy do roboty ani razu. Dzięki czemu możemy sobie tworzyć takie różne warunki nie martwiąc się o optymalizację. Każda z tych metod odda po prostu interfejs IEnumerable.
Enumerator ruszy do pracy dopiero gdy:
sprawdzimy ilość elementów w kolekcji (rozszerzenie Count())
przekonwertujemy IEnumerable na jakąś konkretną kolekcję
wywołamy metodę, która zwraca konkretne dane (np. Single, First, Average itd – one wymagają iterowania po elementach)
będziemy po tym jawnie iterować
Wbij to sobie do głowy, bo łatwo o tym zapomnieć, a potem na twarzy pojawia się wielkie zdziwienie.
W związku z tym, jest jeszcze jedna ciekawa rzecz dotycząca IEnumerable, o której się otwarcie nie mówi…
Załóżmy, że mamy jakąś klasę, która pobiera dane z jakiejś bazy:
class DataReader()
{
public static int[] ReadData()
{
Thread.Sleep(1000); //symulacja długotrwałej operacji
return new int[] { 1, 2, 3, 4, 5 };
}
}
I teraz chcemy te dane wyświetlić:
static void Main(string[] args)
{
foreach(var item in GetData())
{
Console.WriteLine(item);
}
}
static IEnumerable<int> GetData()
{
var data = DataReader.ReadData();
foreach(var d in data)
{
yield return d;
}
}
Spójrz, co się stanie. Pętla foreach będzie chciała enumeratora. Zostanie on stworzony za pomocą yield return. Ale przed jego stworzeniem, trzeba będzie pobrać dane. No i super. W efekcie pobierzemy dane, a potem będziemy je oddawać jeden element po drugim. Dane zostaną pobrane tylko raz.
Ale jeśli coś więcej będziesz chciał zrobić z tymi danymi… chociażby zobaczyć, ile ich jest:
var data = GetData();
int count = data.Count();
foreach(var item in data)
{
Console.WriteLine(item);
}
enumerator zostanie wywołany już dwa razy – dwa razy będziemy pobierać dane z bazy.
Pierwsze wywołanie to będzie rozszerzenie Count – aby policzyć ilość elementów w IEnumerable, to trzeba przeiterować się po wszystkich.
Drugie wywołanie będzie przez pętlę – pętla będzie chciała po prostu poznać wszystkie elementy.
To znaczy, że możesz w taki sposób zniszczyć performance. W pewnych sytuacjach można to odczuć. Sprawdź takie miejsca w swoich programach.
Różnica między IEnumerable i IQueryable
Czuję, że żeby artykuł był pełny, muszę jeszcze nadmienić o tym IQueryable.
IQueryable też ma odłożone wykonanie – podobnie jak IEnumerable. Różnica polega na tym, że IQueryable podczas swojego wykonania (czyli faktycznego wywołania enumeratora) wysyła do bazy danych konkretne zapytanie. Ze wszystkimi już filtrami. Wcześniej możesz sobie te filtry budować, np. za pomocą metody Where – dokładnie tak samo jak w IEnumerable.
Różnica jest po stronie wykonania. IEnumerable całe filtrowanie robi w pamięci, natomiast IQueryable wysyła gotowe zapytanie SQL do serwera i to serwer zwraca już przefiltrowane dane.
To tyle. Mam nadzieję, że teraz Twoja wiedza o iteratorach, enumeratorach, a zwłaszcza o IEnumerable jest pełniejsza 🙂
Jeśli znalazłeś w artykule jakiś błąd albo czegoś nie rozumiesz, koniecznie daj znać w komentarzu.
No i podziel się artykułem z osobami, którym uważasz, że się przyda 🙂
W tym artykule wyjaśnię Ci, czym jest asynchroniczne REST API, czemu i kiedy takie tworzyć. Poza tym powiem Ci jak sobie poradzić z synchronicznym REST API, żeby bez dostępu do kodu uzyskać wersję asynchroniczną. Takie czary 🙂
W międzyczasie ubrudzimy sobie trochę ręce. Przykładowe kody umieściłem na GitHubie. No to jedziemy.
Jak działa REST API?
REST Api możemy podzielić na dwie wersje – synchroniczne i asynchroniczne. Jeśli chodzi o synchroniczne, to sprawa jest dość prosta. Wysyłasz żądanie i czekasz na odpowiedź:
public async Task GenerateReport(string jsonData)
{
var result = await _httpClient.PostAsJsonAsync("orders/report", jsonData);
}
Kod jest prosty i całe flow też. Zobaczmy jak to wygląda w żądaniach HTTP:
klient wysyła żądanie do serwera o wygenerowanie jakiegoś raportu, np.:
POST https://example.com/orders/report
{
"startDate": "2023-01-01",
"endDate": "2023-01-31"
}
serwer odpowiada kodem 400, jeśli przekazane dane są błędne lub 200 OK:
HTTP/1.1 200 OK
Content-Type: application/json
{
"data": <data>
}
Tutaj oczywiście dane raportu mogą pojawić się w BODY lub też dostaniesz adres do pobrania pliku z raportem – w zależności od API.
Gorzej, gdy operacja na serwerze trwa długo. Kilkadziesiąt sekund lub kilka minut. Wtedy taka robota może zakończyć się kilkoma problemami:
możesz otrzymać time-out (brak odpowiedzi z serwera)
tak, czy inaczej używasz wątku, który czeka (na odpowiedź). Może to powodować problemy w wydajności aplikacji, szybsze jej skalowanie w górę i wzrost kosztów związany z chwilowym zwiększonym zapotrzebowaniem na zasoby (zwłaszcza jeśli ruch jest duży).
podatność na atak DDoS
Asynchroniczne REST Api
Jeśli operacja może trwać nieco dłużej niż kilka sekund, lepiej rozważyć jest zrobienie asynchronicznego API. Możesz je zaprojektować na kilka sposobów. Klient może odpytywać serwer co jakiś czas o status operacji lub klient może przekazać webhooka, na który serwer da znać, gdy operacja się zakończy. Prześledźmy obie możliwości:
Odpytywanie serwera
klient wysyła żądanie do serwera, np.:
POST https://example.com/orders/report
{
"startDate": "2023-01-01",
"endDate": "2023-01-31"
}
serwer odpowiada kodem 202 Accepted, dodając nagłówek Location, który wskazuje na endpoint, którym możesz odpytywać o status operacji
serwer rozpoczyna operację (lub częściej – przekazuje ją dalej do wykonania)
co jakiś czas (Retry-After) pytasz o stan operacji, wysyłając żądanie na końcówkę otrzymaną w kroku 2
GET https://example.com/orders/report/status/<id>
możesz dostać odpowiedź 200 OK, wraz z opisem statusu lub 303 See Other ze wskazaniem miejsca, z którego pobierasz rezultat. Przy czym kod 303 oznacza, że operacja się zakończyła.
Przykładowa odpowiedź na operację, która jest w toku:
HTTP/1.1 303 See Other
Location: orders/report/<id>
wysyłasz żądanie po rezultat na końcówkę z nagłówka Location
GET https://example.com/orders/report/<id>
W tym momencie żaden wątek klienta nie był zblokowany i nie czekał aż operacja się wykona. Co więcej, jeśli serwer przekazał operację do wykonania dalej, żaden wątek serwera też nie został zblokowany. Po prostu klient zlecił jakieś zadanie i co jakiś czas odpytywał, czy jest już zrobione (jak to bywa w życiu ;)).
Oczywiście serwer może odpowiedzieć na różne sposoby. W pewnym momencie może się coś wywalić i wtedy pytając o status klient powinien otrzymać informację o błędzie.
Jeśli klient przesyła niepoprawne dane w pierwszym żądaniu, serwer powinien odpowiedzieć kodem 400 Bad Request zamiast 202 Accepted – jak w przypadku synchronicznej wersji.
A niech to serwer… odpowie
Czasem nie chcesz, żeby klient pytał co jakiś czas o stan zadania i wychodzisz z założenia: „Panie, będzie to będzie”. Tak też można. Tutaj sprawa jest nieco prostsza.
klient wysyła żądanie wraz z adresem, na który serwer ma dać odpowiedź
POST https://example.com/orders/report
{
"startDate": "2023-01-01",
"endDate": "2023-01-31",
"callbackUrl": "https://application.com/callback"
}
serwer odpowiada 202 Accepted (lub 400, jeśli dane w żądaniu są nieprawidłowe). Zauważ, że nie podaje tutaj już końcówki do sprawdzania stanu – nagłówka Location. Po prostu – „będzie zrobione, jak się zrobi”
HTTP/1.1 202 Accepted
no i jak już się zrobiło, to tym razem SERWER wysyła żądanie do klienta na wcześniej przekazany callback
Na koniec klient powinien zapytać się o konkretny raport, strzelając na podany endpoint. Oczywiście w zależności od API, serwer też może już w callbacku wysłać wynikowe dane.
Jak to wygląda w praktyce
Zazwyczaj, żeby móc korzystać z czyjegoś API, musisz zarejestrować swojego klienta (swoją aplikację, która będzie to API wykorzystywać). Często podczas rejestracji można podać od razu adres callback, na który serwer ma dawać znać o zakończonym zadaniu lub po prostu wysyłać do Ciebie różne komunikaty – to już zależy od konkretnego API.
Jednak często jest też możliwe wysłanie adresu callbacka w żądaniu, jak to było zrobione w tym przykładzie.
API, po skończonym zadaniu, może od razu wysłać Ci rezultat zamiast odpowiedzi o zakończonym statusie (tak jak w powyższym przykładzie).
Piszemy asynchroniczny serwer
Teraz napiszemy sobie przykładowy asynchroniczny serwer. Zauważ kilka rzeczy:
to jest przykład – dość prosty, acz użyteczny
nie ma tutaj mechanizmu autoryzacji, który powinien być w prawdziwym rozwiązaniu
nie ma tutaj wykonywania prawdziwej operacji, w rzeczywistym przypadku to może być robione na różne sposoby
nie ma tutaj żadnej abstrakcji, piszemy najprościej jak się da, jednak staram się stosować zasady czystego kodu
UWAGA! Ta wersja kodu jest wersją prostą. Bez użycia Azure (albo innej chmury). Weź pod uwagę, że to nie jest do końca asynchroniczne rozwiązanie, jednak jeśli nie znasz Azure, to ta wersja dużo bardziej ułatwi Ci zrozumienie o co w tym chodzi. Wersja wykorzystująca Azure jest opisana niżej.
Na początek stwórzmy sobie standardowe WebApi z kontrolerem do pogody, który za chwilę zmienimy. Do tego stwórzmy serwis WeatherForecastService, który na początek będzie pusty:
public class WeatherForecastService
{
public Task GetForecast(Guid requestId, DateOnly date)
{
return Task.CompletedTask;
}
}
Do tej pory wszystko powinno być jasne. Użytkownik pyta o pogodę na dany dzień. Kontroler wywołuje metodę w serwisie. Dodatkowo kontroler tworzy ID dla tego żądania, które zwraca użytkownikowi. Tutaj ważne jest, że nie czekamy na to aż wykona się Task GetForecast. Nie ma tutaj wywołania z await. To znaczy, że kontroler może zakończyć swoją pracę od razu, a Task będzie działał w tle.
Na koniec kontroler zwraca odpowiednią odpowiedź – 202 Accepted. Zwróć uwagę, że kontroler nie czeka na wykonanie operacji przez serwis. Co to oznacza? W tym momencie nigdy nie dowiemy się, czy operacja się wykonała i jaki jest jej wynik. Dlatego też ten wynik trzeba gdzieś zapisać…
Baza danych
Tak, takie operacje zapisuje się w bazie danych. Stwórzmy więc prosty model bazodanowy i banalną bazę danych – opakowany słownik (weź pod uwagę, że w rzeczywistości powinna być to prawilna baza, ten kod poniżej jest tylko ze względu na prostotę):
public enum OperationStatus
{
NotStarted,
InProgress,
Finished
}
public class WeatherDatabaseItem
{
public Guid RequestId { get; set; }
public OperationStatus Status { get; set; }
public WeatherForecast Data { get; set; }
}
A teraz nasza baza danych:
public class Database
{
private Dictionary<Guid, WeatherDatabaseItem> _weatherForecasts = new();
public void UpsertForecast(Guid id, OperationStatus status, WeatherForecast forecast)
{
WeatherDatabaseItem item = GetOrCreate(id);
item.Status = status;
item.Data = forecast;
_weatherForecasts[id] = item;
}
private WeatherDatabaseItem GetOrCreate(Guid id)
{
WeatherDatabaseItem result = null;
if (!_weatherForecasts.TryGetValue(id, out result))
return new WeatherDatabaseItem { RequestId = id };
return result;
}
}
Żeby taka „baza” miał sens, musimy klasę Database zarejestrować jako singleton:
builder.Services.AddSingleton<Database>();
Serwis
OK, mając bazę danych i kontroler, możemy teraz zrobić jakąś prawdziwą robotę – sprawdzić/wyliczyć prognozę pogody w serwisie. Wstrzyknijmy mu bazę danych i dajmy nieco ciałka:
public class WeatherForecastService
{
private readonly Database _database;
public WeatherForecastService(Database database)
{
_database = database;
}
public async Task GetForecast(Guid requestId, DateOnly date)
{
_database.UpsertForecast(requestId, OperationStatus.InProgress, null);
await Task.Delay(30000); //symulacja długiej operacji
var result = new WeatherForecast
{
Date = date,
Summary = "Sunny",
TemperatureC = 25
};
_database.UpsertForecast(requestId, OperationStatus.Finished, result);
}
}
Zwróć uwagę na dwie rzeczy. Po pierwsze na początku (linia 12) dodajemy pusty rekord do bazy z uzyskanym ID i statusem ustawionym na InProgress. To znaczy, że obliczenia są w trakcie.
Następnie mamy jakiś Delay, który ma tylko symulować długotrwałą operację.
Na koniec dodajemy do bazy gotową prognozę pogody. W międzyczasie klienci mogą pytać się o status operacji i dostaną odpowiedź InProgress.
Zatem musimy jeszcze zrobić dwa endpointy w kontrolerze:
sprawdzanie statusu operacji
pobieranie wyników
Sprawdzanie statusu operacji
Najpierw w bazie danych dodajmy metodę do pobierania odpowiedniego rekordu:
public class Database
{
private Dictionary<Guid, DatabaseItem> _weatherForecasts = new();
public void UpsertForecast(Guid id, OperationStatus status, WeatherForecast forecast)
{
DatabaseItem item = GetOrCreate(id);
item.Status = status;
item.Data = forecast;
_weatherForecasts[id] = item;
}
public DatabaseItem GetById(Guid id)
{
DatabaseItem result = null;
_weatherForecasts.TryGetValue(id, out result);
return result;
}
private DatabaseItem GetOrCreate(Guid id)
{
DatabaseItem result = null;
if (!_weatherForecasts.TryGetValue(id, out result))
return new DatabaseItem { RequestId = id };
return result;
}
}
Teraz w serwisie powinna znaleźć się metoda do pobierania statusu:
public class WeatherForecastService
{
private readonly Database _database;
public WeatherForecastService(Database database)
{
_database = database;
}
public async Task GetForecast(Guid requestId, DateOnly date)
{
_database.UpsertForecast(requestId, OperationStatus.InProgress, null);
await Task.Delay(30000);
var result = new WeatherForecast
{
Date = date,
Summary = "Sunny",
TemperatureC = 25
};
_database.UpsertForecast(requestId, OperationStatus.Finished, result);
return Task.CompletedTask;
}
public async Task<OperationStatus> GetRequestStatus(Guid requestId)
{
var status = await Task.Run(() =>
{
var item = _database.GetById(requestId);
if (item == null)
return OperationStatus.NotStarted;
else
return item.Status;
});
return status;
}
}
Możesz się czepić o to, że metoda GetRequestStatus jest oznaczona jako asynchroniczna, bo w tym przypadku ta asynchroniczność niczego nie daje. Zrobiłem tak tylko po to, żeby utrzymać konwencję pobierania danych z bazy danych jako operację asynchroniczną.
No i na koniec endpoint w kontrolerze:
[HttpGet("Status/{requestId}")]
public async Task<IActionResult> GetStatus(Guid requestId)
{
var status = await _service.GetRequestStatus(requestId);
if(status == Models.OperationStatus.Finished)
{
Response.Headers.Add("Location", $"/WeatherForecast/{requestId}");
return StatusCode(StatusCodes.Status303SeeOther);
} else
{
var data = new
{
status = status
};
return Ok(data);
}
}
Najpierw pobieramy status z serwisu i sprawdzamy go. Jeśli operacja jest zakończona, to odsyłamy klientowi odpowiedź 303 See Other wraz z linkiem do pobrania danych.
Jeśli jednak operacja jest w trakcie, to odsyłamy klientowi rezultat Ok z odpowiednimi danymi.
UWAGA!
Standardowi klienci (przeglądarki internetowe, Postman, a nawet klasa HttpClient) mają wbudowany mechanizm „follow redirects„, co oznacza że po odebraniu odpowiedzi 301, 302 lub 303 automatycznie przeniosą Cię na adres, który będzie w nagłówku Location.
Z jednej strony to fajnie, bo masz załatwioną część pracy. Z drugiej strony jeśli chcesz to przetestować krok po kroku np. Postmanem, to musisz mu wyłączyć opcję „Follow redirect” albo globalnie, albo na poziomie konkretnego requestu:
Niestety nie da się tego wyłączyć w Swaggerze.
Minusy takiego serwera
Oczywiście takie rozwiązanie (opisany serwer) ma swoje minusy, które w zależności od sytuacji można albo zaakceptować, albo nie.
Przede wszystkim tutaj serwer, mimo wszystko, odpowiada za przeprowadzenie długotrwałej operacji. Fakt, żadne wątki nie są blokowane, komunikacja z klientami jest szybka, natomiast jeśli uruchomimy kilka takich zadań, bo dostaniemy żądania od kilku klientów, wtedy nie skorzystamy za bardzo z asynchroniczności. Może się okazać, że aplikacja szybko będzie potrzebowała nowych zasobów i albo je dostanie (wzrost opłat za hosting), albo przestanie odpowiadać i się zblokuje. Daje to też możliwą podatność na atak DDoS.
Oczywiście, jeśli z apki korzysta kilkadziesiąt klientów raz na jakiś czas, to raczej nie ma to znaczenia. Ale już przy kilkuset czy kilku tysiącach, to jest nie do pomyślenia.
Jak zatem sobie z tym poradzić w rzeczywistości?
Odpowiedzią jest chmura.
Serwer asynchroniczny z użyciem chmurki
Pokażę Ci to na przykładzie Microsoft Azure. Jeśli nie wiesz, czym jest Azure, to ten akapit i następne nie dadzą Ci za wiele i na tym możesz skończyć czytanie. Jeśli jednak coś tam wiesz albo jesteś po prostu ciekawy, to czytaj dalej 🙂 Najpierw, z poczucia obowiązku, opiszę Ci bardzo ogólnie trzy usługi, z których będziemy korzystać.
Zakładam że posiadasz subskrypcję Azure’ową i wiesz jak rejestrować podstawowe usługi.
Poniższy przykład nie ma nic wspólnego z bezpieczeństwem. Ze względu na prostotę, wszystkie klucze i hasła będą przekazywane aplikacji w jawny sposób. Nie używamy tutaj KeyVaulta, żeby nie zaciemniać obrazu.
Usługi
Zauważ, że metod na rozwiązanie tego problemu jest zapewne kilka. Ja przedstawię Ci tylko jedną z nich. Oto usługi, z jakich będziemy korzystać:
Storage Queue
Azure Functions
CosmosDb
Oględny opis usług
Storage Queue
StorageQueue to usługa, która daje Ci kolejkę. Możesz kłaść do niej wiadomości, odczytywać je, a także zdejmować je z kolejki.
Azure Functions
Są to funkcje, które mogą być „serverless„, tzn. nie potrzebujesz do ich utrzymywania żadnego serwera. Ma to swoje plusy i minusy. Plusem zdecydowanie są (bardzo) małe koszty.
Potraktuj AzureFunction jak zwykłą funkcję lub metodę. Możesz ją napisać na kilka sposobów i w różnych językach. My się skupimy tutaj na kompilowanej wersji C#.
Dodatkowo funkcje Azurowe mają tzw. triggery – czyli coś, co je uruchamia. Jest wiele wbudowanych triggerów i one właściwie wystarczają. Jednym z nich jest np. wywołanie HTTP, innym – którego będziemy używać – dodanie nowej wiadomości do kolejki Storage Queue.
CosmosDB
CosmosDb to baza danych typu NoSQL. Na Azure znajduje się jej wersja „serverless”, dzięki czemu w prostych zastosowaniach koszty takiej bazy są naprawdę mikroskopijne.
W tej bazie będziemy trzymać dane dotyczące naszych prognoz.
Jeśli nie chcesz tworzyć usług ręcznie, w przykładowym kodzie są pliki BICEP, które utworzą infrastrukturę (o tym jak to zrobić piszę niżej).
Jak utworzyć usługi automatem?
W przykładowych kodach znajdują się pliki BICEP z opisaną strukturą usług. Teraz musisz się upewnić, że masz zainstalowane narzędzie az bicep:
az bicep version
lub je zainstalować:
az bicep install
Następnie za pomocą az musisz zalogować się do swojej subskrypcji na Azure i stworzyć grupę zasobów (dajmy na to: rg-rest-api).
Teraz, mając odpowiednią grupę, możesz uruchomić tworzenie usług. Przejdź w konsoli do katalogu deployment w przykładowych kodach, a następnie:
az deployment group create --resource-group "rg-rest-api" --template-file .\main.bicep
Po chwili wszystkie wymagane usługi będą utworzone w twojej resource grupie.
Tworzymy bazę danych
Na początek utwórzmy bazę danych CosmosDb (For NoSQL).
Tak naprawdę potrzebujemy tylko jednego kontenera. Nazwijmy go operations, a partitionKey ustawmy na requestId. W tym kontenerze będziemy trzymać wszystkie informacje.
Tworzymy kolejkę
Teraz stwórzmy kolejkę (Blob Storage Queue). Nowe wiadomości wpadające do tej kolejki będą odpalać Azurową funkcję, która będzie robiła całą robotę. W tym celu musimy utworzyć StorageAccount.
Jak widzisz, ja utworzyłem storage account o nazwie masterbranchweatherst, a w środku kolejkę o nazwie weather-requests-queue.
Super, została teraz już tylko logika do zrobienia. A to wymaga utworzenia funkcji Azurowej.
Tworzymy funkcję Azurową
Funkcja będzie uruchamiana wcześniej utworzoną kolejką. To znaczy, że jeśli w kolejce znajdzie się jakaś wiadomość, to to zdarzenie uruchomi funkcję i przekaże do niej konkretną wiadomość.
Oczywiście, jeśli w kolejce będzie 100 wiadomości, to jest szansa, że uruchomi się 100 funkcji równolegle. To jednak zależy od kilku czynników, którymi nie będziemy się zajmować w tym artykule. To co jest ważne, to to, że jeśli funkcje Azurowe nie będą w stanie obrobić wszystkich wiadomości od razu, te wiadomości będą po prostu czekać na swoją… kolej. Jak to w kolejce 🙂 Dzięki temu system wciąż będzie wydolny i nie zobaczymy żadnego przeciążenia. Po prostu niektóre wyniki będą nieco później dostępne.
Taka funkcja w najprostszej postaci może wyglądać jak w przykładzie:
Nie omawiam tutaj, jak działają funkcje Azurowe i czym są, zakładam że wiesz to. Ale jeśli chciałbyś przeczytać o tym artykuł daj znać w komentarzu.
Tutaj sprawa jest prosta. Do funkcji trafia wiadomość z kolejki (parametr message). Wiadomość ma właściwość Body, w której znajdzie się json, którego wcześniej wysyłamy (o tym za chwilę).
To, co robimy w linii 22, to deserializujemy tego JSONa do konkretnego obiektu. Następnie (w linii 29) zapisujemy stan naszej operacji w bazie danych – zauważ, że ze statusem InProgress.
Potem symulujemy jakąś długą analizę, na koniec aktualizujemy nasz rekord w bazie danych częściowo losowymi danymi (to tak dla picu, żeby się działo :))
Wszystkie kody zobaczysz w przykładzie, nie jest celem tego artykułu opisywanie ich, bo byłby straaasznie długi. A to zwykła obsługa funkcji azurowej i CosmosDb.
OK, skoro już mamy funkcję azurową uruchamianą przez kolejkę, to teraz trzeba coś do tej kolejki dodać. I tu jest właśnie przeniesienie pracy i rozdzielenie naszej aplikacji na mniejsze części.
Dodajemy wiadomość do kolejki.
Tutaj sprawa jest prosta. To ma działać tak:
klient wysyła żądanie z pytaniem o prognozę pogody
jego żądanie jest wrzucane do kolejki
zwracamy mu odpowiedź 202 Accepted wraz z linkiem do pobierania informacji o statusie jego żądania
Najpierw pokażę Ci klasę, którą napisałem do wrzucenia żądania do kolejki:
public class StorageQueueService
{
private readonly QueueOptions _queueOptions;
public StorageQueueService(IOptions<QueueOptions> queueOptions)
{
_queueOptions = queueOptions.Value;
}
public async Task SendWeatherRequest(WeatherDatabaseItem item)
{
QueueClientOptions clientOptions = new QueueClientOptions
{
MessageEncoding = QueueMessageEncoding.Base64
};
var client = new QueueClient(_queueOptions.ConnectionString,
_queueOptions.WeatherQueueName, clientOptions);
WeatherQueueItem queueItem = new WeatherQueueItem
{
Data = item
};
var serializedData = JsonSerializer.Serialize(queueItem);
await client.SendMessageAsync(serializedData);
}
}
Klasa jest dość prymitywna. Tworzymy ją z opcjami QueueOptions – to jest zwykła klasa trzymająca opcje, które pozwalają na połączenie się z kolejką:
public class QueueOptions
{
public string ConnectionString { get; set; }
public string WeatherQueueName { get; set; }
}
Czyli mamy tutaj connection string do kolejki (w dokładniej do AzureBlobStorage), a także nazwę kolejki, do której chcemy wrzucać te żądania. Więcej o opcjach w .NET pisałem w tym artykule.
Następnie mamy tylko jedną metodę: SendWeatherRequest, która jest odpowiedzialna właśnie za wrzucenie konkretnego żądania na kolejkę. Wrzucamy to w postaci JSON, później otrzymamy to jako wiadomość w naszej funkcji Azure.
WeatherQueueItem to zwykła klasa, którą wykorzystuję dla danych wysyłanych do kolejki. Równie dobrze mógłbym posłużyć się WeatherDatabaseItem, jednak uznałem że tak będzie bardziej prawilnie. Ostatecznie ta wiadomość w kolejce może mieć jakieś dodatkowe dane. Natomiast, jak widzisz, WeatherDatabaseItem jest składnikiem WeatherQueueItem:
public class WeatherQueueItem
{
public WeatherDatabaseItem Data { get; set; }
}
StorageQueueService rejestrujemy jako Scoped (przy okazji konfigurujące opcje):
Ok, mamy prawie działający serwer asynchroniczny. Prawie, ponieważ nie ma tutaj końcówki do pobierania stanu ani wyniku. To będzie po prostu pobranie danych z CosmosDb, a działanie analogiczne do wersji serwera bez chmury.
Teraz, gdy wywołasz końcówkę GetByQueue, do kolejki zostanie dodana odpowiednia wiadomość. Dodanie tej wiadomości uruchomi funkcję Azurową. Funkcja odczyta tę wiadomość i zrobi odpowiednie wpisy w CosmosDb. To tyle.
Tworzenie asynchroniczności przy API synchronicznym
Może się zdarzyć taka sytuacja, że używasz API, które jest synchroniczne, jednak poszczególne żądania działają zbyt długo jak na Twoje wymagania.
W takiej sytuacji również możesz posłużyć się mechanizmem jak wyżej. I nie ma żadnego znaczenia, że nie masz dostępu do kodów API.
Musisz po prostu stworzyć jakąś kolejkę, funkcję Azure’ową i jakąś bazę danych. Teraz zamiast wysyłać żądanie do docelowego API, po prostu umieścisz odpowiedni komunikat w kolejce. Kolejka uruchomi funkcję Azurową, która strzeli do docelowego API. Po tym jak praca się skończy, funkcja Azure’owa może albo wysłać Ci powiadomienie (callback), albo po prostu zmienić dane w bazie, żebyś wiedział, że zadanie zostało zakończone.
Diagram takiej pracy może wyglądać w taki sposób (worker to docelowe API):
To tyle jeśli chodzi o asynchroniczne API. Nie przeczę, że temat może być zawiły zwłaszcza dla osób nie znających chmury lub juniorów. Jeśli czegoś nie zrozumiałeś lub znalazłeś w artykule błąd, koniecznie daj znać w komentarzu.
Obsługujemy pliki cookies. Jeśli uważasz, że to jest ok, po prostu kliknij "Akceptuj wszystko". Możesz też wybrać, jakie chcesz ciasteczka, klikając "Ustawienia".
Przeczytaj naszą politykę cookie
