W Inspeerity w końcu miałem okazję pracować z wyznaczonym architektem w zespole. Pokazali mi ogromną wartość, jaką właściwe decyzje architektoniczne wnoszą do projektu. Zainspirowany tym, postaram się wyjaśnić, czym są te decyzje, jak wpływają na cykl rozwoju i jak Blazor odnosi się do ustalonych wzorców. Wszystkie moje opinie, oczywiście. Miłej lektury!

Czym są wzorce architektoniczne?

Co więc mam na myśli mówiąc o wzorcach? W programowaniu, tak jak w życiu, niektóre problemy pojawiają się raz za razem. Wzorce architektoniczne to wypróbowane i przetestowane sposoby strukturyzacji kodu w celu rozwiązania niektórych z tych problemów. Są to techniki projektowe wyższego poziomu, koncentrujące się na relacjach, odpowiedzialności, regułach i wytycznych w strukturach systemu i komunikacji.

Najlepszą rzeczą jest to, że odnoszą się one do sedna problemu, którym jest architektura, więc mogą być używane niezależnie od języka, frameworka czy środowiska. Żadne dwie implementacje nie będą identyczne, ale jeśli podstawowy problem jest taki sam, właściwy wzorzec architektoniczny może go rozwiązać wielokrotnie. Jest to dziedzina, która zyskuje na znaczeniu szczególnie teraz, wraz z popularyzacją systemów rozproszonych.

To nie tylko bełkot

Dobre decyzje architektoniczne usprawniają wszystkie etapy cyklu rozwoju produktu. Znając strukturę usług, która będzie wymagana - od samego początku można wybrać zoptymalizowany kosztowo plan hostingowy. Utrzymywanie każdego bloku systemu luźno powiązanego zmniejsza koszty i czas konserwacji. Ułatwia to również zwinność w dostarczaniu funkcji, które można następnie dostosować do potrzeb konsumentów. Stosowanie wzorców architektonicznych skraca czas potrzebny na przejście od pomysłu biznesowego do planu wdrożenia. Poprawia również komunikację z zespołami programistycznymi, które mogą być rozproszone.

Powiedziałbym, że nie potrzeba więcej dowodów. Chociaż to, co jest możliwe (a nawet konieczne) w architekturze oprogramowania, ewoluuje z czasem, gdy środowisko staje się coraz bardziej złożone, wzorce pomagają sprostać podstawowym wyzwaniom. Wzorce architektoniczne i rola architekta - nadzorowanie decyzji podejmowanych w projekcie - są niezbędne dla sukcesu produktu.

Przejdźmy do wzorców architektonicznych w Blazor

Na potrzeby tego artykułu, aby nie przerodził się w książkę, założę, że masz podstawowe zrozumienie wszystkich wzorców, które zostaną wymienione. Pokrótce omówię ich znaczenie i głębsze zastosowanie w Blazor.

Coś, co większość będzie wiedzieć: MVVM - Model-View-ViewModel

Jeśli kiedykolwiek zbudowałeś aplikację .NET z interfejsem użytkownika przed Blazor, najprawdopodobniej słyszałeś o wzorcu MVVM. Został on wprowadzony w celu oddzielenia projektu GUI od części backendowej aplikacji. W tym celu wprowadzono strukturę ViewModel jako oprogramowanie pośredniczące w komunikacji między warstwą prezentacji (View) a warstwą domeny (Model). Był on już szeroko wykorzystywany w WPF, więc prawdopodobnie będzie najbardziej znany.

Blazor umożliwia manipulowanie interfejsem użytkownika za pomocą kodu C#. Umożliwia również oddzielenie tego kodu od rzeczywistych znaczników w osobnym pliku. Dzięki temu stosowanie wzorca MVVM może stać się niewyraźne. Ważne jest, aby mieć jasne zrozumienie zadań pisanego kodu. Dopóki jego głównym celem jest umożliwienie interakcji z przeglądarką, powinien być traktowany jako warstwa prezentacji, blok widoku. Tak właśnie traktuje się pliki skryptów w innych frameworkach do tworzenia stron internetowych, prawda? Umieszczenie kodu .NET nie wpływa na strukturę wzorca architektonicznego. Jedna sugestia: nie twórz kodu spaghetti. Jeśli plik razor staje się zbyt złożony, zawsze warto oddzielić znaczniki i C#, a nawet refaktoryzować cały komponent (więcej na ten temat w osobnym artykule).

Co z warstwą logiki prezentacji? Czy ViewModels nadal mają zastosowanie w Blazor? Tak, jeśli tego chcesz. Wzorce są uniwersalne w rozwiązywaniu problemów, niezależnie od zaawansowania samych frameworków. Implementacja ViewModels będzie doskonałym wyborem podczas migracji do tworzenia stron internetowych nowej ery. Zespół będzie już zaznajomiony z podstawami architektury. Blazor został zbudowany na założeniu wielokrotnego użytku. A MVVM pozwala osiągnąć dokładnie to. Rozdzielenie problemów umożliwi również wysoką testowalność logiki prezentacji aplikacji.

Co powiesz na pionowe plasterki?

Architektura Vertical Slices kroi (gra słów zamierzona) aplikację nie poziomo, ale raczej według jej funkcji. Oznacza to oddzielenie bazy kodu zgodnie z jego funkcjonalnością. Jest to naturalny wybór, szczególnie dla aplikacji typu CRUD. Pozwala to na szybkie zlokalizowanie podstawowych problemów lub miejsc do rozszerzenia. Wszystkie pliki, o których mowa, zostaną umieszczone obok siebie. Może to nie działać dobrze w złożonym rozwiązaniu, dodając kolejny poziom złożoności do już zagnieżdżonej struktury projektu.

Pracowałem z monolityczną aplikacją Blazor Server, która działa zgodnie z zasadami Vertical Slices. Logika CQRS została zaimplementowana przy pomocy pakietu MediatR. W idealnym przypadku wymaga to obiektów Request (Query lub Command), Handler i Response. Znaczniki Razor zostały oddzielone od implementacji interaktywności wykonanej w języku C#. Klasa Request została wykorzystana jako model interakcji, a model Response jako model alertu/statusu dla interfejsu użytkownika. Pozwoliło to na stworzenie prostego pliku code-behind Razora, ponieważ jego zadaniem było jedynie delegowanie akcji do odpowiedniego Handlera.

Podejście to pozwoliło w pełni wykorzystać możliwości Blazora i Vertical Slices, jednocześnie ograniczając złożoność implementacji do absolutnego minimum. Mniejsza złożoność oznacza łatwiejszą konserwację i zarządzanie kodem, obniżając koszty.

Jedna czerwona flaga: czy zasady SOLID są nadal przestrzegane w wyżej wymienionej aplikacji i czy powinny?

Święty Graal - projektowanie oparte na domenie

Jak sama nazwa wskazuje, wszystko tutaj koncentruje się na modelu domeny. Projekt zazwyczaj składa się z czterech warstw: UI, Aplikacja, Infrastruktura i wspomniana wcześniej Domena. Jest to prawdopodobnie najbardziej uniwersalny wzorzec, jaki można wybrać, niezależnie od stosu technologicznego. Jeśli chcesz dowiedzieć się więcej o DDD, polecam śledzić Piotra Filipowicza na LinkedIn. I tak, znowu podłączyłem mojego kumpla.

Warstwowanie logiki aplikacji może stać się złożonym tematem, więc nie odgryzaj więcej niż możesz przeżuć, tylko dlatego, że może to być słodkie. Kiedy więc projektowanie oparte na domenie miałoby największy sens w Blazor? W rozwiązaniach, w których WASM i Server są wdrażane razem. Złożone wyzwania wymagają złożonych rozwiązań. Oba procesy byłyby hostowane oddzielnie, ale powinny współdzielić większość logiki. DDD rozwiązuje ten problem. Warstwa infrastruktury jest ujednolicona dla obu środowisk. Domena jest z założenia głównym źródłem logiki i powinna przechowywać większość współdzielonego kodu. Aby osiągnąć luźne połączenie, należy wprowadzić wspólną warstwę, od której będą zależeć wszystkie inne warstwy DDD.

wzorce architektoniczne w blazor

BAMStack to nowy JAMStack

JAMStack to skrót od Java-API-Markup Stack. W tym przypadku warstwa prezentacji, logika prezentacji i logika zaplecza są silnie oddzielone. Wzorzec ten został najpierw przetestowany w przypadku tworzenia stron internetowych opartych na Javie, co pozwoliło uzyskać doskonałe wyniki pod względem skalowalności.

Nic więc dziwnego, że pojawił się BAMStack. Jest to skrót od Blazor-API-Markup Stack i został nieco sformalizowany podczas .NET Conf w 2021 r. Oto link, jeśli chcesz zobaczyć całą sesję. Koncepcja ta została szybko przyjęta z różnych powodów. Po pierwsze, aplikacja zgodna z tymi zasadami jest wysoce skalowalna i ma w tym dużą elastyczność. Backend i frontend mogą być zarządzane oddzielnie. Po drugie, przepływ pracy można łatwo podzielić w zespole, ponieważ przekroje są bardzo ograniczone, co skutkuje szybszą dostawą.

Budujemy aplikację BAMStack dla jednego z naszych klientów w Inspeerity. Jest ona idealnie dopasowana do potrzeb tej firmy. Aplikacja internetowa portalu została zbudowana przy użyciu Blazor. Portale same w sobie są złożonymi rozwiązaniami, więc cała logika została zamknięta w API, co pozwoliło nam utrzymać tę złożoność w ryzach. To powiedziawszy, udowodniło również efektywność pracy z systemami rozproszonymi. Skalowalność może być dokładnie zarządzana, ponieważ przeciążona usługa może być rozszerzona samodzielnie, czy to API, serwer Blazor, czy gniazda SignalR.

Dokonaj wyboru...

...ale jak stworzyć najlepszą? Cóż, zgodnie z nieśmiertelną mądrością przekazywaną z pokolenia na pokolenie, która jest prawdziwa we wszystkich przypadkach użycia: to zależy! Zależy to od potrzeb biznesowych, a także od złożoności rozwiązania, które jest wymagane do ich zaspokojenia. Innym czynnikiem, który należy wziąć pod uwagę, jest baza konsumentów tego produktu - jak duża i jak aktywna będzie?

Z mojego kilkuletniego doświadczenia wynika, że na dzień dzisiejszy najbezpieczniejszym wyborem są aplikacje BAMStack, które również działają zgodnie z zasadami Vertical Slices. Implementacje te najlepiej nadają się do uniwersalnej obsługi większości przypadków biznesowych. Nie komplikują też nadmiernie struktur tam, gdzie nie jest to konieczne.

Zawsze można zaryzykować, ale przy tak wielu opcjach istnieje duże prawdopodobieństwo, że nie będzie to ani optymalny, ani dobry wybór. Zdecydowanie zalecałbym zatrudnienie architekta lub przynajmniej skonsultowanie się z nim...

...lub pozwól nam Ci pomóc

Inspeeriteam z przyjemnością przeanalizuje Twoje potrzeby. Wspólnie ustalmy najlepszy kierunek działania. Moi koledzy z pracy wyróżniają się w tym, co robią, w tym w architekturze. Możemy zbudować coś niezwykłego w Blazor. Ale nasze usługi nie ograniczają się tylko do .NET.

Jak możemy wcielić Twoją wizję w życie?

Wzorce architektury Blazor: co dalej?

Jakieś wzorce, które chciałbyś zobaczyć głębiej? Daj nam znać, chętnie poznamy Twoją opinię.

Ale w następnym artykule przyjrzymy się zarządzaniu stanem aplikacji zarówno na serwerze, jak i dla WASM. Do następnego!

Przeczytaj poprzednie artykuły:

Część 1: Cześć, tu Blazor. Microsoft Blazor. Czy już się znamy?
Część 2: .NET, aplikacje internetowe, chmura, IoT - od czego zacząć i dlaczego odpowiedzią jest Blazor?
Część 3: Blazor - jeden, aby rządzić nimi wszystkimi. A może jest?
Część 4: Jak rozpocząć projekt Blazor prawo?

3.2/5 - (30 votes)