Blazor – użycie Web API

Wprowadzenie

Kilka tygodni temu pojawił się pierwszy artykuł o frameworku Blazor na blogu. Od tamtego czasu zmienił się status frameworka. Wyszedł z fazy eksperymentalnej i aktualnie jest w wersji Preview. Część Server-side zostanie wydana wraz z .NET Core 3.0 we wrześniu 2019. Na stabilną część Client-side działającą na WebAssembly przyjdzie nam poczekać dodatkowy rok, do momentu wydania .NET 5. Ale i tak myślę, że warto już teraz interesować się tym frameworkiem.

W dzisiejszym wpisie będę chciał Ci pokazać, w jaki sposób pobrać dane z Web API. Utworzymy proste rozwiązanie, które z jednej strony będzie udostępniać dane z wykorzystaniem Web API w .NET Core 3.0, a z drugiej strony aplikację w Blazor, która wyśle żądanie o te dane i wyświetli je w widoku.

Utworzenie nowego projektu

W poprzednim wpisie o frameworku Blazor wspomniałem, że w Visual Studio po zainstalowaniu dodatku do Blazora (https://marketplace.visualstudio.com/items?itemName=aspnet.blazor) mamy do dyspozycji dwa szablony do tworzenia projektu. Pierwszy tworzy tylko projekt Blazora, który działa w przeglądarce – i z niego skorzystaliśmy w poprzednim wpisie. Dzisiaj natomiast skorzystamy z tego drugiego szablonu (Blazor ASP.NET Core hosted), który w solution tworzy trzy projekty:

blazor server side solution

Pierwszy projekt (Client) to aplikacja Blazor działająca w przeglądarce. Jest to ten sam projekt, który opisywałem w poprzednim wpisie. Drugi projekt (Server) to projekt Web API w .NET Core, który oczywiście działa po stronie serwera. Ostatni (Shared) to projekt, w którym znajdują się klasy i inne elementy współdzielone między obydwoma projektami.

Ten ostatni projekt, Shared, jest bardzo przydatny. Dzięki temu, że jest współdzielony między frontend oraz backend, możemy zmniejszyć sobie ilość pracy i wrzucać do niego wszystkie obiekty DTO, które zwracają kontrolery w akcjach i do których dane po stronie frontend będą parsowane.

W aktualnych rozwiązaniach, w których na przykład po stronie backendu mamy .NET Core, a po stronie frontendu Angulara (lub inny framework), musimy zawsze wykonywać dodatkową pracę, w ramach której synchronizujemy definicje obiektów DTO. Dodanie nowej właściwości do klasy zwracanej przez kontroler powoduje, że po stronie frontend musimy też dodać tę nową właściwość. Oczywiście takie rozwiązania jak Swagger ułatwiają nam ten proces, ale w przypadku Blazora oraz projektu Shared tak naprawdę tego problemu nie mamy. Co bardzo ułatwia pracę i mnie osobiście się bardzo podoba. 🙂

Darmowy kurs Visual Studio

Pracując z setkami programistów, zauważyłem, że większość osób nie pracuje efektywnie w Visual Studio. W skrajnych przypadkach korzystali z kopiowania z wykorzystaniem menu Edit. Wiem, że to dziwne, ale naprawdę niektórzy tak pracują. Dlatego postanowiłem stworzyć kurs Visual Studio – aby pomóc koleżankom i kolegom w efektywniejszej pracy.

Przygotowałem 20 lekcji e-mail, w których pokażę Ci, w jaki sposób pracować efektywniej i szybciej w Visual Studio. Poznasz dodatki, bez których nie wyobrażam sobie pracy w tym IDE.

Po więcej informacji zapraszam na dedykowaną stronę kursu: Darmowy Kurs Visual Studio.

Quiz C#

Ostatnio przygotowałem również quiz C#, w którym możesz sprawdzić swoją wiedzę. Podejmiesz wyzwanie?

Web API

Omawianie przykładu zaczniemy od części serwerowej. Tak jak wspomniałem wcześniej, w projekcie Shared znajduje się klasa, która reprezentuje dane przesyłane między backend a frontend. W przykładowym projekcie wygląda tak:

W klasie znajdują się cztery właściwości, z czego trzy przechowują dane, natomiast ostatnia przelicza temperaturę z stopni Celsjusza, na Fahrenheity.

Po stronie Web API znajduje się prosty kontroler, który zwraca testowe dane:

W tych dwóch projektach nic nie zmieniałem i zostawiłem to, co zostało wygenerowane przez Visual Studio podczas ich tworzenia.

Blazor Web API

Po stronie aplikacji frontend rozbudowałem trochę kod w stosunku do tego, co wygenerowało Visual Studio. Wcześniej cały kod komunikacji z Web API znajdował się w widoku FetchData.razor (tutaj przy okazji widać, że od poprzedniego wpisu zmieniły się rozszerzenia widoków z cshtml na razor). Natomiast w moim projekcie dodałem dodatkową warstwę usługową, która będzie odpowiedzialna za komunikację z Web API. Sam widok będzie korzystał tylko z tej dodatkowej klasy i będzie wyświetlał zwrócone dane.

Do projektu dodałem folder Services i w nim znajduje się klasa WeatherForecastService, która wyśle żądanie do kontrolera i zwróci zserializowane dane do widoku:

W samej usłudze nie dzieje się nic wielkiego. Wstrzykujemy obiekt klasy HttpClient, a następnie w metodzie GetAsync wysyłamy żądanie do kontrolera i serializujemy dane. Wszystko w sposób asynchroniczny z wykorzystaniem klasy Task oraz słów kluczowych async/await.

Blazor, podobnie jak Web Api w .NET Core, ma wbudowany prosty kontener Dependency Injection. Dlatego po dodaniu klasy usługi i jej interfejsu należy ją zarejestrować w klasie Startup:

Zmiany w widoku

Zanim przejdziemy do użycia w widoku powyższej usługi, warto zrobić jeszcze jedną rzecz. W plikach widoków, podobnie jak w zwykłym kodzie C#, aby skorzystać z jakieś klasy, musimy najpierw ją zaimportować. Na ogół robimy to poprzez dodanie usinga do przestrzeni nazw, w której znajduje się klasa.

W widokach w Blazorze możemy to zrobić na dwa sposoby. Możemy dodać using w pliku widoku lub w pliku _Imports.razor. Ta druga opcja jest o tyle ciekawa, że dodanie tam usinga spowoduje, że wszystkie widoki (np. z folder Pages) będą miały automatycznie dodane te usingi i nie będzie trzeba ich dodawać za każdym razem w pliku widoku. Do pliku _Imports.razor w folderze Pages dodałem usingi do folderu z usługami oraz projektu Shared:

Teraz mogę zmodyfikować widok FetchData.razor, który wyświetla dane pobranie z Web Api i wyświetla w tabelce:

W pliku warto zwrócić uwagę na kilka rzeczy. W pierwszej linii znajduje się dyrektywa page z adresem, pod którym będzie dostępny widok (/fetchdata), w drugiej natomiast znajduje się wstrzyknięcie usługi pobierającej dane.

Na samym końcu znajduje się blok @functions, w którym są dwie rzeczy: pole forecasts dla danych pobranych z usługi oraz metoda OnInitAsync. Metoda ta odpalana jest po załadowaniu widoku i w niej właśnie wywołujemy metodę GetAsync z usługi.

W samym kodzie html mamy ifa, która sprawdza wartość pola forecasts. Gdy na początku wyświetlenia widoku jest nullem, to aplikacja wyświetla informacje o ładowaniu danych. Po ich pobraniu nastąpi wyświetlenie tabelki z wykorzystaniem pętli foreach.

Jak widać, pobranie danych w Blazor z Web Api nie jest niczym skomplikowanym. A dzięki współdzieleniu części kodu jest wręcz przyjemne. 🙂

Przykład

Tradycyjnie na githubie (https://github.com/danielplawgo/BlazorWithApi) znajduje się przykład. Przygotowywałem go w Visual Studio 2019 z zainstalowanym dodatkiem dla Blazora (https://marketplace.visualstudio.com/items?itemName=aspnet.blazor). Po jego pobraniu nie trzeba  robić nic specjalnego, wystarczy tylko uruchomić aplikację.

Podsumowanie

Bardzo ucieszyła mnie informacja o tym, że Blazor wyszedł z fazy eksperymentalnej i jest w wersji preview. Im więcej z niego korzystam, tym bardziej podoba mi się idea korzystania z tych samych narzędzi po stronie backend oraz frontend. Do tego możliwość współdzielenia kodu, w szczególności obiektów DTO przesyłanych między obiema aplikacjami, bardzo wszystko ułatwia.

Już nie mogę się doczekać wersji finalnej frameworka. Ale przed Microsoftem jeszcze dużo pracy nad nim.

Przygotowuję kolejne wpisy na temat Blazor. Daj znać, czy ten temat Cię interesuje. 🙂

Zainteresowany Blazorem? Jak tak to zapraszam na stronę prezentacji Front-end in C#? Yes – Blazor, gdzie znajdziesz więcej materiałów.

11 thoughts on “Blazor – użycie Web API

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *