Model de arhitectură
Organizarea tiparului de arhitectură și interacțiunea dintre componente
Clasificare Există o mare varietate de modele de arhitectură care sunt utilizate în mod sensibil în funcție de sfera și mediul proiectului: Model-View-Controller, Model-View-ViewModel Multi-tier și layer architecture, sisteme distribuite, Domain Driven Design, Hexagonal Architecture Web Area, JavaEE, .Net, Client -Servizor orientat spre servicii (orientat spre proces), de la egal la egal. Client bogat, aplicație GUI Structura internă a componentelor software Reflecție, inversare control, injecție dependență. Sisteme adaptive (componente), decuplare
Model View Controller Controlul prezentării modelului
Problemă/mediu Utilizatori diferiți sau vizualizări ale acelorași date Vizualizare 1: Diagramă circulară ASD: ASD: 95 95 CJA: CJA: 64 64 FBU: FBU: 109 109 JPQ: JPQ: 152 152 SGD: SGD: 204 204 Vizualizare 2: Diagramă cu bare ASD 95 15% CJA 64 10% FBU 109 JPQ 152 18% SGD 33% 204 24% Vizualizare 3: Foaie de calcul
Problemă/mediu Pentru a prezenta un model, sunt generate una sau mai multe vizualizări. Fiecare vizualizare trebuie să se asigure că reflectă corect starea actuală a modelului. Soluție: Observator Fiecare vizualizare se înregistrează la model ca observator. Când modelul se schimbă, acesta notifică toți observatorii. Acest lucru oferă opiniilor posibilitatea de a se adapta. Problemă: evenimente de utilizator
Model-View-Controller Trei părți Ieșire utilizator Introducere utilizator Model View Controller Vizualizare controler Model model Datele și prelucrarea lor Prezentarea datelor Introducere utilizator Decuplarea diferitelor părți ale aplicației mai multă flexibilitate
Vizualizare Afișează datele/informațiile (prezentare) Transmite introducerea utilizatorului către controler Cunoaște controlerul și modelul Este informat despre modificările datelor de către model (observator)
Controler Gestionează una sau mai multe vizualizări. Primește acțiunile utilizatorului (evenimente) din vizualizare și le evaluează. Transmite acțiunile către model. Modelul poate fi informat despre modificările de date (observator) pentru a reacționa la schimbările de stare. Poate controla vizualizarea (schimba vizualizarea, trece la o altă pagină)
Model Partea funcțională a aplicației. Responsabil pentru gestionarea datelor și logica afacerii. Observabil Cunoaște observatorii înregistrați (vizualizări și controlori). Notifică toți observatorii cu privire la date sau modificări de stare.
MVC cu observabil/observator
Tratarea evenimentelor în modelul MVC
Referință la alte tipare Observator Dacă Model View Presenter este de obicei utilizat în MVC, View acționează doar cu Presenter, aceasta este legătura dintre model și View controlează procesele logice dintre celelalte două. Vizualizare model ViewModel MVP cu comandă și legare date
Puncte deschise Distribuția logicii între controler și model? Soluționarea formatării și internaționalizării? Loc pentru validarea datelor introduse de utilizator? Sunt rezolvate diferit în diferite implementări/cadre.
Vizualizare vizualizare model Prezentare de legare de date/vizualizare model
Mediu/Scop Analog cu modelul MVC Separarea reprezentării și logicii Simplificarea interfeței prin legarea datelor
Proprietăți Separarea în părți separate Vizualizarea încapsulează structura UI (de ex. HTML5). ViewModel încapsulează logica de prezentare. Modelul încapsulează logica de afaceri și datele sale. View interacționează cu cuplajul liber ViewModel prin intermediul legării de date și al evenimentelor
Vizualizare Afișează datele/informațiile (prezentare) Primește acțiunile utilizatorului. ViewModel nu cunoaște modelul. Nu este responsabil pentru prelucrarea datelor utilizatorilor. Define legarea datelor și comenzilor la ViewModel. În mod ideal, nu conține nicio logică de afaceri.
Modelul Conține date și logică de afaceri. Accesează backend-ul dacă este necesar. Independent de prezentare (Vizualizare) și control (ViewModel). Responsabil pentru date și metode de manipulare a datelor (operațiuni CRUD).
ViewModel Oferă datele din model și comenzile pentru vizualizarea (una). Implementează logica de acțiune a vederii. Cunoaște modelul, dar nu vizualizarea (numai prin legarea datelor). Abonați-vă la model ca observator. Este notificat de modificările modelului.
Exemplu: Sursă unghiulară: https://angular.io/guide/architecture
Exemplu: Vizualizare unghiulară (View and ViewModel):
lista eroilor
alege un erou din listă
Avantaje Vizualizare mai simplă (aproape fără GlueCode) Ușor schimbabilă Separare strictă a designului și logicii Testabilitate bună Vedere legată de date Se actualizează automat dezavantaje Dezavantaje Complexitate mai mare Observator pe două fețe Efort de calcul ridicat
Aplicația MVVM este utilizată în XAML/WPF JavaFX HTML5 (HTML/JavaScript, de ex. Angular, Knockout).
Arhitectură pe mai multe niveluri și stratificată
Mediul Arhitectura pe mai multe niveluri este un model de arhitectură în care o aplicație este împărțită în mai multe straturi independente (niveluri), care sunt instanțe de rulare separate. Modelul arhitecturii arhitecturale stratificate împarte, de asemenea, aplicația în mai multe straturi, care, totuși, nu sunt de obicei instanțe de rulare independente și separate. În ambele cazuri, apelul vine întotdeauna de la nivelul/nivelul „superior” la „inferior”. Modelul este modelul strat OSI (teoria sistemului de operare).
Categoria/scopul arhitecturii stratificate O arhitectură stratificată este un principiu de structurare utilizat frecvent. O arhitectură stratificată reduce complexitatea dependențelor din sistem.
Categoria/scopul arhitecturii cu mai multe niveluri Subdiviziunea aplicației în mai multe unități de execuție cu sarcini clar definite permite ca aplicația să fie scalată după cum este necesar. Fiecare nivel are propria sarcină clară: împărțirea clară a sarcinilor Arhitectura cuplată redusă cu 3 niveluri: împărțirea aplicației în: Client (de exemplu, client JavaScript, rulează în browserul utilizatorului) Server (logică de afaceri, rulează pe Server X sau în cloud) Baza de date (persistență, rulează pe serverul Y sau în cloud) O arhitectură cu mai multe niveluri necesită utilizarea straturilor, dar nu invers.
Exemplu Arhitectură stratificată Sursă: arhitectură de referință software FDJP
Exemplu Sursă de arhitectură pe mai multe niveluri: https://www.lucidchart.com/pages/uml/deployment-diagram
Avantajele arhitecturii pe mai multe niveluri/arhitecturi pe mai multe niveluri Arhitecturile pe mai multe niveluri sunt ușor scalabile și au un grad ridicat de flexibilitate. Nivele individuale resp. Straturile sunt ușor interschimbabile. Dacă se schimbă interfețele/interfețele, numai cele două niveluri adiacente resp. Straturile afectate. Arhitecturile multi-nivel încapsulează dependențele mașinii și, prin urmare, sunt ușor de transportat. Arhitecturile pe mai multe niveluri permit distribuirea locală a nivelurilor (disponibilitate ridicată, gestionarea riscului de dezastru)
Scalabilitatea Extinderea este de obicei posibilă numai cu hardware scump Arhitectura pe mai multe niveluri este de obicei o condiție prealabilă pentru extindere. În cloud, extinderea este standardul. Aplicații.
Dezavantaje Este adesea dificilă structurarea sistemelor în ordine. Sunt necesare clase/interfețe suplimentare sau chiar interfețe de la distanță între straturi. Cheltuieli suplimentare suplimentare datorate separării în straturi (redirecționarea mesajelor). Probleme de performanță Un număr (prea) mare de straturi determină o structură inutilă de complexă.
Utilizarea arhitecturilor pe mai multe niveluri și straturi este avantajoasă atunci când sunt necesare scalabilitate ridicată și flexibilitate a aplicației. schimbul de straturi individuale ar trebui să fie ușor. Interfețele rămân stabile (interfețe standard). Componentele și platformele hardware/software ar trebui să fie interschimbabile. Platformele hardware/software sunt cumpărate în cloud. ar trebui să fie posibilă subdivizarea componentelor cu funcționalități complexe. sistemul ar trebui creat de mai multe echipe cu responsabilități clare.