Építészeti minta
Az építészeti minta szervezése és az összetevők közötti interakció
Osztályozás A projekt hatókörétől és környezetétől függően sokféle architektúra-minta használható: Model-View-Controller, Model-View-ViewModel Többszintű és rétegű architektúra, elosztott rendszerek, tartományvezérelt tervezés, hatszögletű architektúra webterület, JavaEE, .Net, kliens -Szerver szolgáltatás-orientált (folyamat-orientált), peer-to-peer. Gazdag kliens, grafikus felhasználói felület alkalmazás Szoftverkomponensek belső felépítése Reflekció, A vezérlés megfordítása, Függőség-injektálás. Adaptív (komponens) rendszerek, leválasztás
Model View Controller Modell bemutató vezérlés
Probléma/környezet Ugyanazon adatok különböző felhasználói vagy nézetei 1. nézet: Kördiagram ASD: ASD: 95 95 CJA: CJA: 64 64 FBU: FBU: 109 109 JPQ: JPQ: 152 152 SGD: SGD: 204 204 2. nézet: Sávdiagram ASD 95 15% CJA 64 10% FBU 109 JPQ 152 18% SGD 33% 204 24% 3. nézet: Spread Sheet
Probléma/környezet A modell bemutatásához egy vagy több nézet jön létre. Minden nézetnek biztosítania kell, hogy helyesen tükrözze a modell aktuális állapotát. Megoldás: Megfigyelő Minden nézet megfigyelőként regisztrál a modellel. Amikor a modell változik, értesíti az összes megfigyelőt. Ez lehetőséget ad a nézeteknek az alkalmazkodásra. Probléma: felhasználói események
Model-View-Controller Három rész Kimenet Felhasználói felhasználói bevitel Model View Controller Nézet Vezérlő Controller Model Model adatok és azok feldolgozása Az adatok bemutatása User input Az alkalmazás különböző részeinek leválasztása nagyobb rugalmasság
Megjelenítés Megjeleníti az adatokat/információkat (prezentáció) A felhasználói bemenet továbbítása a vezérlőhöz Tudja a vezérlőt és a modellt A modell tájékoztatja az adatok változásáról
A vezérlő egy vagy esetleg több nézetet kezel, felhasználói nézeteket (eseményeket) fogad a nézetből és kiértékeli azokat. A műveleteket továbbítja a modellhez. A modell tájékoztatást kaphat az adatok változásáról (megfigyelő) annak érdekében, hogy reagáljon az állapotváltozásokra. Vezérelheti a nézetet (nézet módosítása, másik oldalra váltás)
Modell Az alkalmazás funkcionális része. Felelős az adatkezelésért és az üzleti logikáért. Megfigyelhető Ismeri a regisztrált megfigyelőket (nézeteket és vezérlőket). Értesít minden megfigyelőt az adatok vagy állapotváltozásokról
MVC megfigyelhető/megfigyelővel
Eseménykezelés az MVC mintában
Hivatkozás más mintákra Megfigyelő Ha a Model View Presenter-t általában az MVC-ben használják, a View csak az Presenterrel működik, ez a kapcsolat a modell között, és a View a másik kettő közötti logikai folyamatokat vezérli. Model ViewModel MVP parancsokkal és adatkötéssel
Nyitott pontok A logika megoszlása a vezérlő és a modell között? A formázás és az internacionalizáció rendezése? Hely a felhasználói adatok validálásához? Különböző megoldásokban/megoldásokban vannak megoldva.
Model View ViewModel Data-Binding/Model View Presenter
Környezet/Cél analóg az MVC mintával A reprezentáció és a logika elválasztása Az interfész egyszerűsítése adatkötéssel
Tulajdonságok Szétválasztás külön részekre A nézet a felhasználói felület struktúráját foglalja magában (pl. HTML5). A ViewModel a prezentációs logikát foglalja magában. A modell az üzleti logikát és annak adatait foglalja magában. A View adatkötés és események révén kölcsönhatásba lép a ViewModel laza csatolásával
Nézet Megjeleníti az adatokat/információkat (prezentációt) Fogadja a felhasználói műveleteket. A ViewModel nem ismeri a modellt. Nem felelős a felhasználói adatok feldolgozásáért. Meghatározza az adatok és a parancsok összerendelését a ViewModelhez. Ideális esetben nem tartalmaz üzleti logikát.
A modell adatokat és üzleti logikát tartalmaz. Szükség esetén hozzáfér a háttérprogramhoz. A prezentációtól (View) és a vezérléstől (ViewModel) független. Felelős adatokért és adatkezelési módszerekért (CRUD műveletek).
ViewModel Megadja a modell adatait és az (egy) nézet parancsait. Megvalósítja a nézet cselekvési logikáját. Ismeri a modellt, de a nézetet nem (csak adatkötés útján). Feliratkozás a modellre megfigyelőként. Értesítést kap a modell változásairól.
Példa: Szögforrás: https://angular.io/guide/architecture
Példa: Szögletes (View és ViewModel) nézet:
hőslista
válasszon ki egy hősöt a listáról
Előnyök Egyszerűbb nézet (szinte nincs GlueCode) Könnyen cserélhető A tervezés és a logika szigorú elkülönítése Jó tesztelhetőség Az adatokhoz kötött nézet automatikusan frissíti Hátrányok Nagyobb komplexitás Kétoldalas megfigyelő Nagy számítási erőfeszítés
Az MVVM alkalmazást XAML/WPF JavaFX HTML5-ben használják (HTML/JavaScript, pl. Angular, Knockout).
Többszintű és réteges architektúra
Környezet A többszintű architektúra egy olyan architektúraminta, amelyben az alkalmazás több független rétegre (szintre) van felosztva, amelyek külön futásidejű példányok. A réteges architektúra-minta szintén több rétegre osztja az alkalmazást, amelyek azonban általában nem mindegyik független és külön futásidejű példány. Mindkét esetben a hívás mindig a „magasabb” -tól az „alsó” rétegig/rétegig érkezik. A modell az OSI réteg modellje (operációs rendszer elmélet).
A réteges architektúra kategóriája/célja A réteg architektúra gyakran használt strukturálási elv. A réteg architektúra csökkenti a rendszeren belüli függőségek összetettségét. Feladatok egyértelmű felosztása Alacsony összekapcsolási rétegek megakadályozzák a ciklusokat a függőségi gráfban. A rétegek jól érthetők (jól definiált feladatuk miatt).
A többszintű architektúra kategóriája/célja Az alkalmazás felosztása több futási egységre, világosan meghatározott feladatokkal lehetővé teszi az alkalmazás szükség szerinti méretezését. Minden rétegnek megvan a maga egyértelmű feladata: A feladatok egyértelmű felosztása Alacsony csatolású 3-szintes architektúra: Az alkalmazás felosztása: Ügyfél (pl. JavaScript kliens, a felhasználó böngészőjében fut) Szerver (üzleti logika, Server X vagy felhőben fut) Adatbázis (perzisztencia, fut az Y szerveren vagy a felhőben) A többszintű architektúra rétegek használatát igényli, de fordítva nem.
Példa rétegzett architektúrára Forrás: FDJP szoftver referencia architektúra
Példa többszintű architektúra forrására: https://www.lucidchart.com/pages/uml/deployment-diagram
A többszintű/réteges architektúra előnyei A többszintű architektúrák könnyen méretezhetők és nagyfokú rugalmassággal bírnak. Egyéni szintek ill. A rétegek könnyen felcserélhetők. Az interfészek/interfészek megváltoztatása esetén csak a két szomszédos szint ill. Érintett rétegek. A többszintű architektúrák a gépfüggőségeket foglalják magukba, ezért könnyen hordozhatóak. A többszintű architektúrák lehetővé teszik a szintek helyi elosztását (magas rendelkezésre állás, katasztrófakockázat-kezelés)
Méretezhetőség A nagyítás általában csak drága hardver esetén lehetséges. A többlépcsős architektúra általában a méretezés előfeltétele. A felhőben a méretezés a szabványos Felhő dinamikusan méretezhető a terhelés alapján Többszintű, és ezért a réteges architektúra is a mai vállalkozás standardja Alkalmazások.
Hátrányok Gyakran nehéz rendszereket rendesen rétegenként felépíteni. A rétegek között további osztályokra/interfészekre vagy akár távoli interfészekre van szükség. További rétegek a rétegekbe történő szétválasztás (üzenetek továbbítása) miatt Teljesítményproblémák A (túl) nagy számú réteg szükségtelenül összetett struktúrát okoz
A többrétegű és többrétegű architektúrák használata akkor előnyös, ha az alkalmazás nagy skálázhatóságára és rugalmasságára van szükség. az egyes rétegek cseréjének könnyűnek kell lennie. Az interfészek stabilak maradnak (standard interfészek). Az alkatrészeknek és a hardver/szoftver platformoknak felcserélhetőknek kell lenniük. A hardver/szoftver platformokat a felhőben vásárolják meg. lehetővé kell tenni az összetett funkcionalitású komponensek további felosztását. a rendszert több, egyértelmű felelősséggel rendelkező csapatnak kell létrehoznia.