2022. március 9., szerda

Alkalmazási keretrendszer a felhőben (13B)

Személyre szabhatóság

Az előbb feltüntetett ok mellett ez a másik, ami miatt nagyon sokan szeretik az egyedi fejlesztésű keretrendszereket: teljes mértékben személyre szabhatók, az igényeink szerint. Igaz, hogy több időbe telhet a különböző függvényeket, osztályokat rendesen definiálni, viszont soha nem eshetünk bele abba a hibába, hogy nem tudjuk a megfelelő módon személyre szabni azt, amit szeretnénk, amire az ügyfélnek igénye lenne.

Egy ismert, már készen létrehozott keretrendszer esetén egy szükséges módosítás sokkal költségesebb, és nehezebb lehet.

Biztonság

Az ismert frameworkok alapvetően nagyon jó securityvel rendelkeznek, szinte kivétel nélkül. Ennek nyilvánvalóan az az oka, hogy nagyon sok ember használja őket, és ezért maximálisan odafigyelnek arra, hogy ilyen téren ne lehessenek hiányosságok az applikációnkban. Illetve, ha van valami biztonsági rés, azt fixálják, és onnantól kezdve ez egyetlen installált projektben sem fog előjönni többet.

Az egyénileg készített keretrendszerekben sokszor komolyabb biztonsági rések is vannak: jelszavak tárolása, CSRF védelem, XSS támadás, Session kezelés, és a többi. Még ha egy cég sok éve is használ egy egyedileg készített struktúrát, sem lesz olyan jó securityja, mint egy olyan applikációé, melynek az alapját egy olyan rendszer képzi, aminek a folyamatos preparálásáért több száz fejlesztő felel, és kapnak folyamatos visszajelzéseket.

Ez természetesen nem jelenti azt, hogy nem lehetne biztonságos keretrendszert írni, de ilyen szinten az legfeljebb olyan teljesítményt fog nyújtani, mint ismert vetélytársaik.

Méret

Szintén egy komoly érv lehet a mai, jól ismert keretrendszerek ellen, hogy alapból óriási méretűek. Egy felinstallált Laravel keretrendszer például 60-80 MB-nyi helyet foglal el a szerverünkön, és akkor ott még semmilyen package nem került felinstallálásra. Összeségében véve, mindennel együtt meghízhat az applikációnk akár több száz MB-os méretre is.

Egy egyedi keretrendszer, melyet mi készítünk, rosszabb esetben sem fog 1-2 MB fölé lépni. A CodeIgniter például, egy "elég" alap ismert keretrendszernek számít, és és csupán 1-2 MB-nyi méretű alapból.

Az applikáció gyorsasága, optimalizáltság

Az betöltési idő általában véve gyorsabb egyedi keretrendszerek esetében. Mivel kisebb méretűek, ezért kevesebb dolog van, ami lassítja az applikáció működését. Ezen felül, sokkal optimalizáltabbak-pontosabban kevesebb optimalizálási hiba van bennük-mint az ismert keretrendszerekben. A Laravel Eloquentje például nem optimalizált annyira, nem fognak olyan gyorsan működni az adatbázis-lekérések mint egy kisebb, egyedi architektúra esetén lenne ez így.

A fejlesztés gyorsasága

A fejlesztés-véleményem szerint-alapvetően gyorsabb egy ismert keretrendszerben, mint egy egyediben. A Laravel Eloquentje például, amivel adatbázis lekéréseket, módosításokat lehet csinálni, rendkívül sok előre megírt, funkcióval rendelkezik, és mivel az "igények" sokszor nagyon hasonlóak programozók részéről, ezért ezekhez is igazítják az újabb verziókat.

Alkalmazás keretrendszer

Az alkalmazás keretrendszer felhasználói felület összetevőket tartalmaz alkalmazások fejlesztéséhez, és az azokhoz hozzáférést biztosító szervezi összetevőket.

A felhasználói felület vezérlőelemekből áll (mint például a szövegmezők, gombok és lapok), és az egyes vezérlőelemekhez attribútumok tartoznak, melyek meghatározzák a viselkedésüket. Az egyes alkalmazások rendelkeznek egy presentation.xml fájllal, amely tartalmazza az alkalmazás felhasználói felületének összeállításához szükséges összes információt. Amikor létrehoz egy alkalmazást, az automatikusan hozzáadásra kerül a modulok és alkalmazások navigációs struktúrájához.

Felhasználói felület vezérlőelemek

A vezérlőelemek előre meghatározott összetevők, amelyek az alkalmazásablak elemeit állítják össze. Az Alkalmazástervezőben kiválaszthat egyéni vezérlőelemeket, megtekintheti és módosíthatja a vezérlőelem tulajdonságokat, vagy új vezérlőelemeket húzhat be az alkalmazásba a Vezérlőelem paletta összetevőből. A vezérlőelem kódja nem módosítható, de viselkedése igen, ha megfelelő értékeket ad meg a vezérlőelem tulajdonságok ablakában. Beállíthatja például, hogy a vezérlőelem egy kötelező mező legyen, társíthatja a vezérlőelemet egy kikeresési táblázathoz, vagy összekötheti a vezérlőelemet egy eseménnyel.

Néhány vezérlőelem, mint a szakaszok, a lapcsoportok vagy a gombok, tároló vezérlőelemek. A legtöbb tároló vezérlőelem egyetlen rendeltetése más vezérlőelemek tárolása. A nem tároló vezérlőelemeket a tároló vezérlőelemeken belül kell elhelyezni. Az Alkalmazástervezőben áthúzhat vezérlőelemeket a Vezérlőelem paletta összetevőből az alkalmazás munkaterületére, majd módosíthatja a vezérlőelemet a Vezérlőelem tulajdonságok ablakban.

A vezérlőelemek helyzete relatív más vezérlőelemekhez, nem képpontokra vagy egy rácsra alapul, és lehetővé teszi a szakaszok és a szakaszoszlopok szélességének dinamikus méretezését. Ha egy szakasz például különböző szélességű mezőket tartalmaz, akkor minden mező szélessége automatikusan a szakasz legszélesebb mezőjének a szélességére lesz beállítva.

Alkalmazás XML fájlok

Minden alkalmazás rendelkezik egy presentation.xml fájllal, amely tartalmazza az alkalmazás felhasználói felületének összeállításához szükséges összes információt. Minden presentation.xml fájlt a MAXPRESENTATION tábla tárol az adatbázisban. A vezérlőelemek előre meghatározott összetevők, amelyek az alkalmazásablak elemeit állítják össze. Az Alkalmazástervezőben kiválaszthat egyéni vezérlőelemeket, megtekintheti és módosíthatja a vezérlőelem tulajdonságokat, vagy új vezérlőelemeket húzhat be az alkalmazásba a Vezérlőelem paletta összetevőből. A vezérlőelem kódja nem módosítható, de viselkedése igen, ha megfelelő értékeket ad meg a vezérlőelem tulajdonságok ablakában. Beállíthatja például, hogy a vezérlőelem egy kötelező mező legyen, társíthatja a vezérlőelemet egy kikeresési táblázathoz, vagy összekötheti a vezérlőelemet egy eseménnyel.

Az alkalmazás presentation.xml fájlja egy címkét tartalmaz az alkalmazás felhasználói felületén használt minden egyes vezérlőelemhez. Minden vezérlőelem egyedi azonosítóval rendelkezik, amely eldönti, hogyan viselkedik a vezérlőelem, amikor megjeleníti az alkalmazást. A vezérlőelem címkék relatív helye a presentation.xml fájlban határozza meg az alkalmazás ablakban megjelenő felhasználói felület elemek elrendezését és sorrendjét.

Amikor a felhasználó elindít egy alkalmazást, a presentation.xml fájl lekérésre kerül az adatbázisból, és elhelyezésre kerül az alkalmazáskiszolgáló memóriájában. A alkalmazási keretrendszer beolvassa an kódokat az egyes vezérlőelemekhez, és létrehozza azok HTML leírását, a presentation.xml fájlban megadott attribútumok alapján. Az előállítási folyamat növekményes, és az alkalmazáskiszolgáló memóriája tárolja az egyes vezérlőelemek HTML leírásait, amíg az alkalmazás ablakban az összes vezérlőelem előállításra nem kerül. Az összes HTML elem előállítása után az alkalmazáskiszolgáló átadja a HTML elemeket a felhasználói webböngészőnek (az ügyfélnek). A presentation.xml fájlt a kiszolgáló gyorsítótára őrzi meg, készenlétben a következő alkalomra, mikor egy felhasználó eléri az alkalmazást.

Amikor megnyit egy alkalmazást az alkalmazástervezőben, a presentation.xml fájl betöltődik a memóriába. Az elvégzett módosítások csak a fájl tárolt verzióját érintik, amíg el nem menti az alkalmazást. A presentation.xml fájl mentésekor a módosított információk véglegesítve lesznek az adatbázisban, így ezután láthatja a változásokat az alkalmazás megnyitásakor.

Bár az alkalmazás legtöbb módosítását végrehajthatja az Alkalmazástervezőben, szükség esetén a presentation.xml fájlt is szerkesztheti. Néha a presentation.xml fájl szerkesztése a leghatékonyabb megközelítés, például egy adott kifejezés módosítása keresés és felülírás használatával. Több lappal és ablakkal rendelkező alkalmazás esetében ehhez a feladathoz meg kell nyitnia minden egyes ablakot az Alkalmazástervezőben, ami egyrészt időigényes, másrészt sok hibalehetőséget rejt. Néhány alkalmazás rejtett lapokat használ, melyek nem láthatók az Alkalmazástervezőben. Ezeket a lapokat nem lehet módosítani az Alkalmazástervezőben, így módosításukhoz a szerkeszteni kell a presentation.xml fájlt.

Alkalmazások felépítése

Minden alkalmazást modulok tárolnak. Amikor alkalmazást hoz létre, meg kell adni annak modulját, és a létrehozandó alkalmazás típusát. Az alkalmazásoknak három különböző típusa van, bár mindhárom típus ugyanazt a struktúrát és ugyanazokat az összetevőket használja. Az elérhető alkalmazástípusok az alábbiak:
A teljesítményalkalmazás a szabványos alkalmazástípus, mely több lapot, egy Művelet kiválasztása menüt és eszköztár gombokat tartalmaz.
Az önkiszolgáló alkalmazás rekordokat hoz létre, és nem tartalmaz Lista táblázat ablakot vagy eszköztárat.
Az egyoldalas alkalmazásban nincsenek lapok, de tartalmazhat Művelet kiválasztása menüt és eszköztár gombokat.
Miután létrehozott egy alkalmazást, az hozzáadásra kerül az Ugrás menühöz a létrehozásakor megadott modulon belülk.





Források:

https://gyires.inf.unideb.hu/GyBITT/31/ch18s04.html
https://webiskola.hu/php-ismeretek/a-legjobb-php-keretrendszerek/
http://ade.web.elte.hu/wabp/lecke7_lap1.html
http://hu.telusuri.info/articles/windows-10/kak-uznat-kakie-versii-net-framework-ustanovleni-na-kompyutere.html



Nincsenek megjegyzések:

Megjegyzés küldése