Wybieranie między tradycyjnymi aplikacjami internetowymi i aplikacjami jednostronicowymi (SPA)
Napiwek
Ta zawartość jest fragmentem książki eBook, architekta nowoczesnych aplikacji internetowych z platformą ASP.NET Core i platformą Azure, dostępnym na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
"Prawo Atwooda: Każda aplikacja, którą można napisać w języku JavaScript, zostanie ostatecznie napisana w języku JavaScript".
- Jeff Atwood
Obecnie istnieją dwa ogólne podejścia do tworzenia aplikacji internetowych: tradycyjne aplikacje internetowe, które wykonują większość logiki aplikacji na serwerze, oraz aplikacje jednostronicowe (SPA), które wykonują większość logiki interfejsu użytkownika w przeglądarce internetowej, komunikując się z serwerem internetowym głównie przy użyciu internetowych interfejsów API. Możliwe jest również podejście hybrydowe, najprostsze jest hostowanie co najmniej jednego bogatego podaplikacji spa w większej tradycyjnej aplikacji internetowej.
Użyj tradycyjnych aplikacji internetowych, gdy:
Wymagania po stronie klienta aplikacji są proste, a nawet tylko do odczytu.
Aplikacja musi działać w przeglądarkach bez obsługi języka JavaScript.
Twoja aplikacja jest publiczna i korzysta z odnajdywania i odwołań z wyszukiwarki.
Użyj SPA, gdy:
Aplikacja musi uwidocznić bogaty interfejs użytkownika z wieloma funkcjami.
Twój zespół zna język JavaScript, TypeScript lub BlazorWebAssembly programowanie.
Aplikacja musi już uwidocznić interfejs API dla innych (wewnętrznych lub publicznych) klientów.
Ponadto struktury SPA wymagają większej wiedzy na temat architektury i bezpieczeństwa. Mają one większe współczynniki zmian ze względu na częste aktualizacje i nowe struktury klienta niż tradycyjne aplikacje internetowe. Konfigurowanie zautomatyzowanych procesów kompilacji i wdrażania oraz korzystanie z opcji wdrażania, takich jak kontenery, może być trudniejsze w przypadku aplikacji SPA niż tradycyjne aplikacje internetowe.
Ulepszenia w środowisku użytkownika, które można wprowadzić w podejściu SPA, należy rozważyć w odniesieniu do tych zagadnień.
Blazor
ASP.NET Core zawiera model umożliwiający tworzenie rozbudowanych, interaktywnych i komponowalnych interfejsów użytkownika o nazwie Blazor. Blazor Po stronie serwera deweloperzy mogą tworzyć interfejs użytkownika za pomocą języka C# i razor na serwerze, a interfejs użytkownika może być interaktywnie połączony z przeglądarką w czasie rzeczywistym przy użyciu trwałego połączenia usługi SignalR. BlazorWebAssembly wprowadza inną opcję dla Blazor aplikacji, umożliwiając uruchamianie ich w przeglądarce przy użyciu polecenia WebAssembly. Ponieważ jest to prawdziwy kod platformy .NET uruchomiony w systemie WebAssembly, można ponownie użyć kodu i bibliotek z części po stronie serwera aplikacji.
Blazor udostępnia nową, trzecią opcję do rozważenia podczas oceny, czy utworzyć wyłącznie wyrenderowaną przez serwer aplikację internetową, czy SPA. Możesz tworzyć zaawansowane, podobne do SPA zachowania po stronie klienta przy użyciu , Blazorbez konieczności znaczącego programowania w języku JavaScript. Blazor aplikacje mogą wywoływać interfejsy API w celu żądania danych lub wykonywania operacji po stronie serwera. Mogą współpracować z językiem JavaScript, jeśli jest to konieczne, aby korzystać z bibliotek i struktur języka JavaScript.
Rozważ utworzenie aplikacji Blazor internetowej przy użyciu następującego polecenia:
Aplikacja musi uwidocznić bogaty interfejs użytkownika
Twój zespół jest bardziej wygodny w programach dla platformy .NET niż programowanie w języku JavaScript lub TypeScript
Jeśli masz istniejącą aplikację formularzy internetowych, którą rozważasz migrację do platformy .NET Core lub najnowszej platformy .NET, możesz przejrzeć bezpłatną książkę elektroniczną, aby deweloperzy formularzy internetowych mogli sprawdzić, Blazor czy warto rozważyć migrację do Blazorusługi .
Aby uzyskać więcej informacji na temat Blazorprogramu , zobacz Wprowadzenie do Blazorusługi .
Kiedy wybrać tradycyjne aplikacje internetowe
Poniższa sekcja zawiera bardziej szczegółowe wyjaśnienie wcześniej określonych przyczyn wybierania tradycyjnych aplikacji internetowych.
Aplikacja ma proste, prawdopodobnie tylko do odczytu, wymagania po stronie klienta
Wiele aplikacji internetowych jest używanych głównie w sposób tylko do odczytu przez zdecydowaną większość użytkowników. Aplikacje tylko do odczytu (lub głównie do odczytu) wydają się być znacznie prostsze niż te aplikacje, które utrzymują i manipulują dużym stanem. Na przykład aparat wyszukiwania może składać się z pojedynczego punktu wejścia z polem tekstowym i drugą stroną do wyświetlania wyników wyszukiwania. Użytkownicy anonimowi mogą łatwo wysyłać żądania i nie ma potrzeby logiki po stronie klienta. Podobnie aplikacja publiczna systemu zarządzania zawartością lub bloga zwykle składa się głównie z zawartości z niewielkim zachowaniem po stronie klienta. Takie aplikacje są łatwo tworzone jako tradycyjne aplikacje internetowe oparte na serwerze, które wykonują logikę na serwerze internetowym i renderują kod HTML, który ma być wyświetlany w przeglądarce. Fakt, że każda unikatowa strona witryny ma własny adres URL, który można dodać do zakładek i indeksować przez wyszukiwarki (domyślnie bez konieczności dodawania tej funkcji jako osobnej funkcji aplikacji) jest również wyraźną korzyścią w takich scenariuszach.
Aplikacja musi działać w przeglądarkach bez obsługi języka JavaScript
Aplikacje internetowe, które muszą działać w przeglądarkach z ograniczoną liczbą lub żadną obsługą języka JavaScript, powinny być napisane przy użyciu tradycyjnych przepływów pracy aplikacji internetowej (lub przynajmniej mieć możliwość powrotu do takiego zachowania). Dodatki SPA wymagają języka JavaScript po stronie klienta, aby działały; jeśli nie jest dostępna, dostawcy usług nie są dobrym wyborem.
Twój zespół nie jest wie, jak pisać w języku JavaScript lub technikach programowania języka TypeScript
Jeśli Twój zespół nie zna języka JavaScript lub TypeScript, ale jest zaznajomiony z tworzeniem aplikacji internetowych po stronie serwera, prawdopodobnie będzie mógł dostarczać tradycyjną aplikację internetową szybciej niż SPA. Jeśli nie nauczysz się programować SPAs jest celem, lub środowisko użytkownika zapewniane przez SPA jest wymagane, tradycyjne aplikacje internetowe są bardziej produktywnym wyborem dla zespołów, które już znają ich tworzenie.
Kiedy wybrać umowy SPA
Poniższa sekcja zawiera bardziej szczegółowe wyjaśnienie, kiedy wybrać styl programowania aplikacji jednostronicowych dla aplikacji internetowej.
Aplikacja musi uwidocznić bogaty interfejs użytkownika z wieloma funkcjami
Dostawcy usług mogą obsługiwać rozbudowane funkcje po stronie klienta, które nie wymagają ponownego ładowania strony, ponieważ użytkownicy podejmują działania lub nawigują między obszarami aplikacji. Dostawcy usług mogą ładować szybciej, pobierać dane w tle, a poszczególne akcje użytkownika są bardziej dynamiczne, ponieważ ponowne ładowanie pełnej strony jest rzadkie. Dostawcy usług mogą obsługiwać aktualizacje przyrostowe, zapisując częściowo wypełnione formularze lub dokumenty bez konieczności klikania przycisku w celu przesłania formularza. Dostawcy usług mogą obsługiwać zaawansowane zachowania po stronie klienta, takie jak przeciąganie i upuszczanie, znacznie bardziej czytelnie niż tradycyjne aplikacje. Nazwy SPA można zaprojektować tak, aby były uruchamiane w trybie rozłączonym, co powoduje aktualizację modelu po stronie klienta, który ostatecznie jest synchronizowany z powrotem z serwerem po ponownym nawiązaniu połączenia. Wybierz aplikację w stylu SPA, jeśli wymagania aplikacji obejmują zaawansowane funkcje wykraczające poza typową ofertę formularzy HTML.
Często dostawcy usług muszą implementować funkcje wbudowane w tradycyjne aplikacje internetowe, takie jak wyświetlanie znaczącego adresu URL na pasku adresu odzwierciedlające bieżącą operację (i umożliwienie użytkownikom tworzenia zakładek lub linku głębokiego do tego adresu URL w celu powrotu do niego). Dostawcy usług powinni również umożliwić użytkownikom korzystanie z przycisków wstecz i przesyłania dalej przeglądarki z wynikami, które ich nie zaskakują.
Twój zespół jest zaznajomiony z programowaniem w języku JavaScript i/lub TypeScript
Pisanie umów SPA wymaga znajomości języków JavaScript i/lub TypeScript oraz technik i bibliotek programowania po stronie klienta. Twój zespół powinien być kompetentny w pisaniu nowoczesnego języka JavaScript przy użyciu struktury SPA, takiej jak Angular.
Odwołania — struktury SPA
- Angular: https://angular.io
- React: https://reactjs.org/
- Vue.js:https://vuejs.org/
Aplikacja musi już uwidocznić interfejs API dla innych (wewnętrznych lub publicznych) klientów
Jeśli już obsługujesz internetowy interfejs API do użytku przez innych klientów, może to wymagać mniejszego nakładu pracy w celu utworzenia implementacji SPA, która korzysta z tych interfejsów API, a nie odtwarzania logiki w formularzu po stronie serwera. Dostawcy usług korzystają z internetowych interfejsów API w celu wykonywania zapytań i aktualizowania danych w miarę interakcji użytkowników z aplikacją.
Kiedy wybrać Blazor
Poniższa sekcja zawiera bardziej szczegółowe wyjaśnienie, kiedy wybrać Blazor aplikację internetową.
Aplikacja musi uwidocznić bogaty interfejs użytkownika
Podobnie jak w przypadku umów SPA opartych na języku JavaScript, Blazor aplikacje mogą obsługiwać zaawansowane zachowanie klienta bez ponownego ładowania strony. Te aplikacje są bardziej dynamiczne dla użytkowników, pobierając tylko dane (lub HTML) wymagane do reagowania na daną interakcję użytkownika. Prawidłowo zaprojektowane aplikacje po stronie serwera można skonfigurować tak, aby były uruchamiane jako aplikacje po stronie BlazorBlazor klienta z minimalnymi zmianami, gdy ta funkcja jest obsługiwana.
Twój zespół jest bardziej wygodny w programach dla platformy .NET niż programowanie w języku JavaScript lub TypeScript
Wielu deweloperów jest bardziej wydajnych dzięki platformom .NET i Razor niż w językach po stronie klienta, takich jak JavaScript lub TypeScript. Ponieważ strona serwera aplikacji jest już opracowywana przy użyciu platformy .NET, dzięki Blazor temu każdy deweloper platformy .NET w zespole może zrozumieć i potencjalnie utworzyć zachowanie frontonu aplikacji.
Tabela decyzyjna
Poniższa tabela decyzyjna zawiera podsumowanie niektórych podstawowych czynników, które należy wziąć pod uwagę podczas wybierania między tradycyjną aplikacją internetową, SPA lub aplikacją Blazor .
Współczynnik | Tradycyjna aplikacja internetowa | Aplikacja jednostronicowa | Blazor App |
---|---|---|---|
Wymagana znajomość języka JavaScript/TypeScript | Minimalne | Wymagane | Minimalne |
Obsługa przeglądarek bez skryptów | Obsługiwane | Nieobsługiwane | Obsługiwane |
Minimalne zachowanie aplikacji po stronie klienta | Dobrze dopasowane | Overkill | Opłacalne |
Rozbudowane, złożone wymagania dotyczące interfejsu użytkownika | Ograniczone | Dobrze dopasowane | Dobrze dopasowane |
Inne uwagi
Tradycyjne aplikacje internetowe wydają się być prostsze i mają lepsze kryteria optymalizacji aparatu wyszukiwania (SEO) niż aplikacje SPA. Boty aparatu wyszukiwania mogą łatwo korzystać z zawartości z tradycyjnych aplikacji, natomiast obsługa indeksowania spA może być niewystarczająca lub ograniczona. Jeśli Aplikacja korzysta z publicznego odnajdywania przez wyszukiwarki, często jest to ważne.
Ponadto, o ile nie utworzono narzędzia do zarządzania zawartością SPA, może to wymagać od deweloperów wprowadzenia zmian. Tradycyjne aplikacje internetowe są często łatwiejsze dla innych deweloperów do wprowadzania zmian, ponieważ większość zawartości jest po prostu HTML i może nie wymagać procesu kompilacji do podglądu, a nawet wdrożenia. Jeśli użytkownicy niebędący deweloperami w organizacji prawdopodobnie będą musieli zachować zawartość aplikacji, tradycyjna aplikacja internetowa może być lepszym wyborem.
SpAs świeci, gdy aplikacja ma złożone interaktywne formularze lub inne funkcje interakcji użytkownika. W przypadku złożonych aplikacji, które wymagają uwierzytelniania do użycia, a tym samym nie są dostępne przez publiczne pająki wyszukiwarki, spAs są doskonałym rozwiązaniem w wielu przypadkach.