Uporaba ogrodja CSLA.NET za implementacijo poslovnega nivoja

2. Uporaba ogrodja CSLA.NET za implementacijo poslovnega nivoja dr. Danijel Radjenović SLODUG 18. 9. 2014

3. Agenda • Porazdeljene aplikacije • Logična arhitektura • Fizična arhitektura • Porazdeljenost poslovne logike • Funkcionalnost ogrodja CSLA .NET

4. 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

5. Porazdeljene aplikacije

6. Običajna 3. nivojska delitev

7. Še ena 3. nivojska delitev

8. Kakšna je razlika?

9. 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

10. 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

11. Prednosti fizične n-nivojske arhitekture • Učinkovitost (angl. “Performance”) • Razširljivost (angl. “Scalability”) • Odpornost na napake (angl. “Fault Tolerance”) • Varnost (angl. “Security”)

12. 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

13. 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

14. 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)

15. Logična arhitektura

16. 5-nivojska logična arhitektura

17. 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

18. 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)

19. 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)

20. 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)

21. Podatkovna baza (angl. “Data Storage and Management”) • Fizično shranjevanja podatkov • SQL Server, Oracle, …

22. Fizična arhitektura

23. 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”)

24. Eno-nivojska fizična arhitektura

25. 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

26. Dvo-nivojska fizična arhitektura

27. 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

28. Tri-nivojska fizična arhitektura – pametni odjemalec

29. 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

30. Tri-nivojska fizična arhitektura – spletni odjemalec

31. 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

32. Štiri-nivojska fizična arhitektura – spletni odjemalec

33. Š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%

34. Tri-nivojska fizična arhitektura – spletni odjemalec

35. 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

36. Porazdeljenost poslovne logike

37. Težave upravljanja s poslovno logiko • Podvajanje kode • Sinhronizacija podvojene kode • Vzdrževanje • Preglednost • Rešitev: centraliziranost • Vendar: kje, kako ?

38. Potencialne lokacije poslovne logike

39. 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

40. 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

41. 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

42. 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

43. 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

44. Ogrodje CSLA .NET

45. 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)

46. 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

47. Stereotipi objektov • Editableroot • Editablechild • Editable, “switchable” (i.e., root or child) object • Editablerootcollection • Editablechildcollection

48. Stereotipi objektov • Read-onlyroot • Read-onlyrootcollection • Read-onlychild • Read-onlychildcollection

49. Stereotipi objektov • Commandobject • Name/value list • Dynamiceditable list • Dynamiceditableroot • Criteria

50. Osnovna terminologija