540 likes | 749 Views
Uporaba ogrodja CSLA.NET za implementacijo poslovnega nivoja. d r. Danijel Radjenović. SLODUG 18. 9. 2014. Agenda. Porazdeljene aplikacije Logična arhitektura Fizična arhitektura Porazdeljenost poslovne logike Funkcionalnost ogrodja CSLA .NET. Motivacija. Vmesnik
E N D
Uporaba ogrodja CSLA.NET za implementacijo poslovnega nivoja dr. Danijel Radjenović SLODUG 18. 9. 2014
Agenda • Porazdeljene aplikacije • Logična arhitektura • Fizična arhitektura • Porazdeljenost poslovne logike • Funkcionalnost ogrodja CSLA .NET
Motivacija • Vmesnik • WPF, ASP.NET, Windows Forms, WCF • Nadzor nad vmesnikom • Viewmodel(MVVM) , Controller (MVC), Code-behind • Poslovna logika • Csla • Dostop do podatkov • ADO.NET, ADO.NET EntityFramework, NHibernate • Podatkovna baza • SQL Server, Oracle, DB2, MySQL
Razlika med logično in fizično arhitekturo • Fizična arhitektura • Aplikacija razdeljena na več računalnikov z različnimi funkcijami • Logična arhitektura • Delitev različnih tipov funkcionalnosti • Relacija med logično in fizično arhitekturo • Fizičnih nivojev ne more biti več kot je logičnih
Prednosti logične n-nivojske arhitekture • Logično organizirana koda • Enostavnejše vzdrževanje • Ponovna uporaba kode • Teamski razvoj • Preglednost kode • Neodvisnost med nivoji (lažja zamenjava) • Fleksibilnost pri nameščanju
Prednosti fizične n-nivojske arhitekture • Učinkovitost (angl. “Performance”) • Razširljivost (angl. “Scalability”) • Odpornost na napake (angl. “Fault Tolerance”) • Varnost (angl. “Security”)
Kompleksnost N-nivojskih aplikacij • N-nivojske aplikacije so običajno bolj kompleksne kot eno-nivojske • Zmanjšujejo kompleksnost • Velike ali kompleksne aplikacije • Povečujejo kompleksnost • Male ali preproste aplikacije • Obstaja verjetnost, da tudi male in preproste aplikacije s časom zrastejo v velike in kompleksne
Koliko logičnih nivojev • Običajna 3-nivojska logična zasnova • uporabniški vmesnik • poslovna logika • podatkovni nivo • Danes večinoma ne zadostuje • Uporabniški vmesnik je lahko fizično razdeljen na dva dela (brskalnik in spletni strežnik) • Poslovna logika je pogosto fizično razdeljena na odjemalca in aplikacijski strežnik • Pojavlja se tudi nivo dostopa do podatkov • Moderne aplikacije imajo danes običajno med 4 in 6 logičnih nivojev
Komunikacija med nivoji • Organiziranost kode po nivojih še ne pomeni, da lahko te nivoje nameščamo poljubno po fizičnih nivojih, če komunikacija med nivoji ni ustrezno načrtovana • Pogosto imamo mrežno komunikacijo med poslovnim in podatkovnim nivojem • Mrežna komunikacija med predstavitvenim in poslovnim nivojem je nepraktična in nezaželena (data binding)
Vmesnik (angl. “Interface”) • Vmesnik ali uporabniški vmesnik ali predstavitveni nivo • Prikaz zaslonskih mask in sprejemanje uporabniških zahtev • XAML (View - MVVM) • HTML (WebForms, ASP.NET MVC) • Windows Forms (VS designer) • XML (SOA) • JSON
Nadzor nad vmesnikom (angl. “Interface Control”) • Event-driven - odziv na uporabniške zahteve (vnose, klike…) • Posrednik med uporabnikom in poslovnim nivojem: • Posreduje uporabnikove zahteve poslovnemu nivoju • Vrača rezultat uporabniku • ViewModel (MVVM) • Codebehind (Windows forms) • Controler (ASP.NET MVC) • Presenter (MVP)
Poslovna logika (angl. “Business Logic”) • Poslovna pravila, validacija podatkov, manipulacija podatkov, procesiranje, avtorizacija • Poslovna logika mora biti ločena od predstavitvenega nivoja (ponovna uporaba, vzdrževanje) • Načrtovalski vzorci MVC, MVP, MVVM – poslovna logika je v modelu in je ločena od predstavitvenega nivoja • Poslovni nivo je lahko nameščenih na več fizičnih nivojih hkrati (odjemalec in strežnik)
Dostop do podatkov (angl. “Data Access”) • Vmesnik med poslovnim nivojem in podatkovno bazo • Komunicira s podatkovno bazo (CRUDL) • Zamenjava ponudnika podatkovne baze • Zamenjava tehnologije dostopa do podatkov • Microsoft (DAO, RDO, ADO 1.0, ADO 2.0, ADO.NET, DataSet/TableAdapter, LINQ to SQL in ADO.NET EntityFramework)
Podatkovna baza (angl. “Data Storage and Management”) • Fizično shranjevanja podatkov • SQL Server, Oracle, …
Fizična arhitektura • Uporaba logične 5-nivojske arhitekture • Možne konfiguracije: • Eno-, dvo-, tro-, štiri- in pet-nivojska fizična arhitektura • Iskanje kompromisa med: • Učinkovitost (angl. “Performance”) • Razširljivost (angl. “Scalability”) • Varnost (angl. “Security”) • Odpornost na napake (angl. “ Fault Tolerance”)
Eno-nivojska fizična arhitektura • Optimalna hitrost (predstavitveni in poslovni nivo tečeta znotraj istega procesa, komunicirata z lokalno bazo) • Samostojna okolja, ki ne potrebujejo interakcije z ostalimi sistemi oz. uporabniki • Slaba razširljivost • Ne podpira več hkratnih uporabnikov • Tudi 5-nivojska logična arhitektura se lahko namesti na enega odjemalca
Dvo-nivojska fizična arhitektura • Debeli odjemalec (angl. „Fat Client“) • Podobna eno-nivojski, edino podatkovna baza je na skupnem, centralnem podatkovnem strežniku • Podpora več hkratnim uporabnikom • Dobra učinkovitost • SQL Server premore tudi par sto istočasnih uporabnikov
Tri-nivojska fizična arhitektura – pametni odjemalec • Razširljivost • Večje število uporabnikov (dobra ocena palca: nad 50 do 100 hkratnih uporabnikov) • Varnost • Samo aplikacijski strežnik ima dostop do podatkovne baze • Porazdelitev bremena • Centraliziran dostop do baze • connection pooling • 150 do 200 hkratnih uporabnikov s samo 2 ali 3 povezavama na bazo • Poslovni nivo nameščen na odjemalcu in strežniku
Tri-nivojska fizična arhitektura – spletni odjemalec • Najboljša učinkovitost (single process on a single machine) • Minimiziranje fizičnih nivojev in mrežne komunikacije • Možno izboljšati učinkovitost in razširljivost hkrati, a vendar na račun varnosti
Štiri-nivojska fizična arhitektura – spletni odjemalec • Izboljšana varnost • Web server je v DMZ • Stisjen med 2 požarna zidova • Ne komunicira direktno s podatkovno bazo • Učinkovitost -50%
Tri-nivojska fizična arhitektura – spletni odjemalec • Dobra razširljivost, učinkovitost in odpornost na napake • Več paralelnih spletnih strežnikov (web farm) • Pade strežnik ali je preobremenjen, nič hudega, delo prevzame drugi strežnik • Porazdelitev bremena
Težave upravljanja s poslovno logiko • Podvajanje kode • Sinhronizacija podvojene kode • Vzdrževanje • Preglednost • Rešitev: centraliziranost • Vendar: kje, kako ?
Poslovna logika v podatkovni bazi • Logika je centralizirana • Neinteraktivna uporabniška izkušnja • Uporabnik ne dobi potrdila ali so podatki veljavni, dokler jih ne poizkusi zapisati • Podatkovni strežnik je preobremenjen (opravlja vso delo) • Podatkovni strežnik je najtežje nadgraditi • Zahtevne load-balancing tehnike • Alternativa: večji in večji strežnik
Poslovna logika v nadzorniku vmesnika • Logika je centralizirana(vsaj v teoriji), v praksi pa razpršena po UI in pomešana z UI kodo • Lahko uporabljamo jezike kot je C# • Slaba ponovna uporaba • Logika se nahaja na posamezni strani • Neinteraktivnost (strežniške aplikacije) • ASP.NET validationcontrols, ASP.NET MVC DataAnnotations delno rešujejo ta problem
Poslovna logika v nivoju dostopa do podatkov • Neinteraktivna uporabniška izkušnja • Vsaka zahteva je posredovana do nivoja dostopa do podatkov • Problem učinkovitosti, če imamo poslovni nivo na ločenem aplikacijskem strežniku • Latenca mreže • Preobremenjenost aplikacijskega strežnika
Rešitev • Centralizacija poslovne logike v poslovnem nivoju, ki je nameščen na • Odjemalcu in • Interakcija z uporabnikom • Na voljo nadzorniku vmesnika • Interaktivna uporabniška izkušnja • Aplikacijskem strežniku • Interakcija s podatkovno bazo • Na voljo nivoju dostopa do podatkov • Učinkovito procesiranje v povezavi z bazo
Mobilni poslovni objekti • Mobilni – potujejo med logičnimi nivoji • Tudi preko “žice” med računalniki • Od nivoja dostopa do podatkov do vmesnika in nazaj • Poslovni – vsebujejo podatke in poslovno logiko • “Pametni” objekti • Dostop do podatkov mogoč samo skozi poslovno logiko • Poslovne logike ni mogoče zaobiti
Funkcionalnost ogrodja • Validacija in urejanje seznama prekršenih pravil • Standardna implementacija poslovnih in validacijskih pravil • Spremljanje stanja objekta • N-nivojska fizična arhitektura, mobilni objekti (prenos objekta med fizičnimi nivoji preko mreže) • Integrirana avtorizacijska pravila na nivoju objekta in lastnosti (angl. “property”) • Močno tipizirana kolekcija objektov tipa starš-otrok (parent-child relacija)
Funkcionalnost ogrodja • N-nivojska razveljavitev sprememb • Preprost in abstrakten model za razvijalce uporabniškega vmesnika (objekt kot črna škatla) • Polna podpora za “data binding” za vse .NET vmesnike (WPF, Windows Forms, WebForms, ASP.NET MVC, Silverlight, WP7) • Shranjevanje objektov v podatkovno bazo in pridobivanje iz nje • Lastna avtentikacija • Razširljivost
Stereotipi objektov • Editableroot • Editablechild • Editable, “switchable” (i.e., root or child) object • Editablerootcollection • Editablechildcollection
Stereotipi objektov • Read-onlyroot • Read-onlyrootcollection • Read-onlychild • Read-onlychildcollection
Stereotipi objektov • Commandobject • Name/value list • Dynamiceditable list • Dynamiceditableroot • Criteria