Választás a hagyományos webalkalmazások és az egyoldalas alkalmazások (SPA-k) között

Tipp.

Ez a tartalom egy részlet az eBook, Architect Modern Web Applications with ASP.NET Core és Az Azure, elérhető a .NET Docs vagy egy ingyenesen letölthető PDF, amely offline olvasható.

PDF letöltése

"Atwood törvénye: Minden olyan alkalmazás, amely JavaScriptben írható, végül JavaScriptben lesz megírva."
- Jeff Atwood

A webalkalmazások készítésének két általános megközelítése van: a hagyományos webalkalmazások, amelyek a legtöbb alkalmazáslogikát végrehajtják a kiszolgálón, és az egyoldalas alkalmazások (SLA-k), amelyek a felhasználói felület logikájának nagy részét egy webböngészőben hajtják végre, és elsősorban webes API-kat használva kommunikálnak a webkiszolgálóval. Hibrid megközelítés is lehetséges, a legegyszerűbb, ha egy vagy több gazdag SPA-szerű alalkalmazást üzemeltet egy nagyobb hagyományos webalkalmazásban.

Hagyományos webalkalmazások használata a következő esetekben:

• Az alkalmazás ügyféloldali követelményei egyszerűek vagy írásvédettek.

• Az alkalmazásnak JavaScript-támogatás nélkül kell működnie a böngészőkben.

• Az alkalmazás nyilvános elérésű, és a keresőmotorok felderítésének és javaslatainak előnyei.

Spa-t akkor használjon, ha:

• Az alkalmazásnak számos funkcióval rendelkező, gazdag felhasználói felületet kell elérhetővé tennie.

• A csapat ismeri a JavaScriptet, a TypeScriptet vagy a BlazorWebAssembly fejlesztést.

• Az alkalmazásnak már közzé kell tennie egy API-t más (belső vagy nyilvános) ügyfelek számára.

Emellett az SPA-keretrendszerek nagyobb architekturális és biztonsági szakértelmet igényelnek. A gyakori frissítések és az új ügyfél-keretrendszerek miatt nagyobb a változás, mint a hagyományos webalkalmazások esetében. Az automatizált buildelési és üzembehelyezési folyamatok konfigurálása és az üzembehelyezési lehetőségek, például a tárolók használata nehezebb lehet a SPA-alkalmazásokkal, mint a hagyományos webalkalmazásokkal.

Az SPA megközelítés által lehetővé tett felhasználói élmény javulását mérlegelni kell ezen szempontok alapján.

Blazor

ASP.NET Core tartalmaz egy modellt a gazdag, interaktív és írható felhasználói felületek, úgynevezett Blazor. Blazor A kiszolgálóoldal lehetővé teszi a fejlesztők számára, hogy A C# és a Razor használatával építsenek felhasználói felületet a kiszolgálón, és hogy a felhasználói felület interaktív módon, valós időben csatlakozva legyen a böngészőhöz egy állandó SignalR-kapcsolat használatával. BlazorWebAssembly bevezet egy másik lehetőséget az alkalmazások számára, lehetővé téve számukra Blazor , hogy futtassanak a böngészőben a WebAssembly. Mivel valós .NET-kód fut rajta WebAssembly, újra felhasználhatja az alkalmazás kiszolgálóoldali részeiből származó kódokat és kódtárakat.

Blazor egy új, harmadik lehetőséget kínál, amelyet érdemes megfontolni annak kiértékelésekor, hogy tisztán kiszolgáló által renderelt webalkalmazást vagy SPA-t szeretne-e létrehozni. Gazdag, SPA-szerű ügyféloldali viselkedéseket Blazorhozhat létre anélkül, hogy jelentős JavaScript-fejlesztésre lenne szükség. Blazor az alkalmazások meghívhatják az API-kat adatok lekérésére vagy kiszolgálóoldali műveletek végrehajtására. Szükség esetén együttműködhetnek a JavaScripttel, hogy kihasználhassák a JavaScript-kódtárak és -keretrendszerek előnyeit.

Érdemes lehet a webalkalmazást a következőkkel felépíteni Blazor :

• Az alkalmazásnak gazdag felhasználói felületet kell elérhetővé tennie

• Csapatának kényelmesebb a .NET-fejlesztés, mint a JavaScript vagy a TypeScript fejlesztése

Ha van egy meglévő webes űrlapalkalmazása, amely a .NET Core-ra vagy a legújabb .NET-re való migrálást fontolgatja, érdemes lehet áttekinteni az ingyenes e-könyvet, Blazor hogy a webűrlapok fejlesztői megtekintse, érdemes-e áttelepíteni.Blazor

További információ: BlazorElső lépésekBlazor.

Mikor érdemes hagyományos webalkalmazásokat választani?

Az alábbi szakasz részletesebben ismerteti a hagyományos webalkalmazások kiválasztásának korábban említett okait.

Az alkalmazás egyszerű, esetleg írásvédett ügyféloldali követelményekkel rendelkezik

Számos webalkalmazást elsősorban írásvédett módon használnak a felhasználók túlnyomó többsége. Az írásvédett (vagy többnyire írásvédett) alkalmazások általában sokkal egyszerűbbek, mint azok az alkalmazások, amelyek nagy mennyiségű állapotot tartanak fenn és kezelnek. A keresőmotorok például egyetlen belépési pontból és egy szövegmezőből és egy második oldalból állhatnak a keresési eredmények megjelenítéséhez. A névtelen felhasználók egyszerűen kérhetnek kéréseket, és nincs szükség ügyféloldali logikára. Hasonlóképpen, a blog vagy a tartalomkezelő rendszer nyilvános elérésű alkalmazása általában főként olyan tartalmakból áll, amelyeket kevés ügyféloldali viselkedéssel lehet létrehozni. Az ilyen alkalmazások könnyen felépíthetők hagyományos kiszolgálóalapú webalkalmazásokként, amelyek logikát végeznek a webkiszolgálón, és html-t renderelnek, hogy megjelenjenek a böngészőben. Az ilyen helyzetekben az is egyértelmű előny, hogy a webhely minden egyedi oldalának saját URL-címe van, amelyet a keresőmotorok könyvjelzővel és indexeléssel is megjelölhetnek (alapértelmezés szerint anélkül, hogy ezt a funkciót külön funkcióként kellene hozzáadniuk az alkalmazáshoz).

Az alkalmazásnak JavaScript-támogatás nélkül kell működnie a böngészőkben

Azokat a webalkalmazásokat, amelyeknek korlátozott vagy javaScript-támogatással nem rendelkező böngészőkben kell működni, hagyományos webalkalmazás-munkafolyamatokkal kell írniuk (vagy legalábbis vissza kell tudniuk esni az ilyen viselkedésre). Az SA-k működéséhez ügyféloldali JavaScript szükséges; ha nem érhető el, az SLA-k nem jó választás.

Csapata nem ismeri a JavaScript- vagy TypeScript-fejlesztési technikákat

Ha a csapata nem ismeri a JavaScriptet vagy a TypeScriptet, de ismeri a kiszolgálóoldali webalkalmazás-fejlesztést, akkor valószínűleg gyorsabban képesek lesznek egy hagyományos webalkalmazást biztosítani, mint egy SPA-t. Hacsak nem cél az SLA-k programozásának elsajátítása, vagy a SPA által biztosított felhasználói élmény szükséges, a hagyományos webalkalmazások hatékonyabb választást jelentenek azoknak a csapatoknak, akik már ismerik az összeállításukat.

Mikor érdemes az SA-kat választani?

Az alábbi szakasz részletesebben ismerteti, hogy mikor érdemes egyoldalas alkalmazásstílust választani a webalkalmazáshoz.

Az alkalmazásnak számos funkcióval rendelkező, gazdag felhasználói felületet kell elérhetővé tennie

Az SLA-k olyan gazdag ügyféloldali funkciókat támogathatnak, amelyek nem igénylik a lap újbóli betöltését, amikor a felhasználók műveleteket végeznek, vagy navigálnak az alkalmazás egyes területei között. Az SLA-k gyorsabban tölthetők be, adatokat tölthetnek le a háttérben, és az egyes felhasználói műveletek rugalmasabbak, mivel a teljes oldal újrabetöltése ritkán fordul elő. Az SLA-k támogathatják a növekményes frissítéseket, és a részben kitöltött űrlapokat vagy dokumentumokat anélkül menthetik, hogy a felhasználónak egy gombra kellene kattintania az űrlap elküldéséhez. Az SLA-k sokkal könnyebben támogatják az ügyféloldali viselkedést, például a húzást és a húzást, mint a hagyományos alkalmazások. Az SLA-k úgy tervezhetők, hogy leválasztott módban fussanak, így az ügyféloldali modell frissítései végül szinkronizálódnak a kiszolgálóra a kapcsolat újbóli létrehozása után. Válasszon SPA-stílusú alkalmazást, ha az alkalmazás követelményei olyan sokoldalú funkciókat tartalmaznak, amelyek túlmutatnak a tipikus HTML-űrlapok által kínált funkciókon.

Az SLA-knak gyakran olyan funkciókat kell implementálniuk, amelyek a hagyományos webalkalmazásokba vannak beépítve, például megjelenítenek egy értelmes URL-címet a címsorban, amely az aktuális műveletet tükrözi (és lehetővé teszi a felhasználók számára, hogy könyvjelzővel vagy az URL-re mutató mélyhivatkozással térjenek vissza). Az SLA-knak lehetővé kell tenniük, hogy a felhasználók a böngésző vissza- és továbbítási gombjait olyan eredményekkel használják, amelyek nem lepik meg őket.

A csapat ismeri a JavaScript és/vagy TypeScript-fejlesztést

Az SLA-k írásához ismerni kell a JavaScriptet és/vagy a TypeScriptet, valamint az ügyféloldali programozási technikákat és kódtárakat. A csapatának hozzáértőnek kell lennie a modern JavaScript írásához egy SPA-keretrendszer, például az Angular használatával.

Hivatkozások – SPA-keretrendszerek

• Szögletes: https://angular.io
• Reagálás: https://reactjs.org/
• Vue.js:https://vuejs.org/

Az alkalmazásnak már közzé kell tennie egy API-t más (belső vagy nyilvános) ügyfelek számára

Ha már támogatja a webes API-t más ügyfelek általi használatra, előfordulhat, hogy kevesebb erőfeszítést igényel egy OLYAN SPA-implementáció létrehozása, amely ezeket az API-kat használja ahelyett, hogy kiszolgálóoldali formában reprodukálja a logikát. Az SLA-k széles körben használják a webes API-kat az adatok lekérdezésére és frissítésére, miközben a felhasználók az alkalmazással kommunikálnak.

Mikor érdemes választani? Blazor

Az alábbi szakasz részletesebben ismerteti, hogy mikor érdemes a webalkalmazást választani Blazor .

Az alkalmazásnak gazdag felhasználói felületet kell elérhetővé tennie

A JavaScript-alapú SA-khoz hasonlóan az Blazor alkalmazások is támogathatják a gazdag ügyfél viselkedését lapbetöltések nélkül. Ezek az alkalmazások jobban reagálnak a felhasználókra, és csak az adott felhasználói beavatkozáshoz szükséges adatokat (vagy HTML-eket) kérik le. A megfelelően megtervezett kiszolgálóoldali Blazor alkalmazások úgy konfigurálhatók, hogy ügyféloldali Blazor alkalmazásként fussanak, minimális módosításokkal, miután ez a funkció támogatott.

Csapatának kényelmesebb a .NET-fejlesztés, mint a JavaScript vagy a TypeScript fejlesztése

A .NET és a Razor használatával sok fejlesztő hatékonyabb, mint az ügyféloldali nyelvek, például a JavaScript vagy a TypeScript. Mivel az alkalmazás kiszolgálóoldala már fejlesztés alatt áll a .NET-tel Blazor , biztosítja, hogy a csapat minden .NET-fejlesztője megértse és potenciálisan felépítse az alkalmazás előtérének viselkedését.

Döntési táblázat

Az alábbi döntési táblázat összefoglalja azokat az alapvető tényezőket, amelyeket figyelembe kell venni egy hagyományos webalkalmazás, spa vagy Blazor alkalmazás kiválasztásakor.

Tényező	Hagyományos webalkalmazás	Egyoldalas alkalmazás	Blazor App
A JavaScript/TypeScript szükséges csapatszintű ismerete	Minimális	Szükséges	Minimális
Szkriptelés nélküli böngészők támogatása	Támogatott	Nem támogatott	Támogatott
Az ügyféloldali alkalmazások minimális viselkedése	Jól illeszkedő	Túlzás	Életképes
Részletes, összetett felhasználói felületi követelmények	Korlátozott	Jól illeszkedő	Jól illeszkedő

Egyéb szempontok

A hagyományos webalkalmazások általában egyszerűbbek, és jobb keresőmotor-optimalizálási (Standard kiadás O) feltételekkel rendelkeznek, mint a SPA-alkalmazások. A keresőmotor-robotok könnyen felhasználhatják a hagyományos alkalmazásokból származó tartalmakat, míg az indexelő SA-k támogatása nem vagy csak korlátozott lehet. Ha az alkalmazás a keresőmotorok által történő nyilvános felderítés előnyeit élvezi, ez gyakran fontos szempont.

Ezenkívül, ha nem készített felügyeleti eszközt a SPA-tartalomhoz, előfordulhat, hogy a fejlesztőknek módosításokat kell végrehajtaniuk. A hagyományos webalkalmazások gyakran könnyebben módosíthatók a nem fejlesztők számára, mivel a tartalom nagy része egyszerűen HTML, és előfordulhat, hogy nincs szükség buildelési folyamatra az előzetes verzió megtekintéséhez vagy üzembe helyezéséhez. Ha a szervezet nem fejlesztőinek valószínűleg fenn kell tartaniuk az alkalmazás tartalmát, egy hagyományos webalkalmazás jobb választás lehet.

Az SLA-k akkor ragyognak, ha az alkalmazás összetett interaktív űrlapokkal vagy más felhasználói interakciós funkciókkal rendelkezik. Az olyan összetett alkalmazások esetében, amelyek hitelesítést igényelnek, és így a nyilvános keresőmotorok nem férnek hozzá, az SLA-k sok esetben nagyszerű választásnak bizonyulnak.

Előzőkövetkező