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

3

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 Entity Framework, NHibernate

• Podatkovna baza– SQL Server, Oracle, DB2, MySQL

4

Porazdeljene aplikacije

Običajna 3. nivojska delitev

Predstavitveni nivo

Poslovni nivo

Podatkovni nivo6

Še ena 3. nivojska delitev

Delovna postaja

Aplikacijski strežnik

Podatkovni strežnik7

Kakšna je razlika?

Logična arhitektu

ra:Predstavitveni nivo

Poslovni nivo

Podatkovni nivo

Fizična arhitektu

ra:Delovna postaja

Aplikacijski strežnik

Podatkovni strežnik

8

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

9

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

10

Prednosti fizične n-nivojske arhitekture

• Učinkovitost (angl. “Performance”)• Razširljivost (angl. “Scalability”)• Odpornost na napake (angl. “Fault

Tolerance”)• Varnost (angl. “Security”)

11

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

12

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)

Logična arhitektura

5-nivojska logična arhitektura

Interface

Interface ControlBusiness Logic

Data Access

Data Storage and Management

16

Vmesnik (angl. “Interface”)

• Vmesnik ali uporabniški vmesnik ali predstavitveni nivo

• Prikaz zaslonskih mask in sprejemanje uporabniških zahtev

• XAML (View - MVVM)• HTML (Web Forms, ASP.NET MVC)• Windows Forms (VS designer)• XML (SOA)• JSON

17

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)• Code behind (Windows forms)• Controler (ASP.NET MVC)• Presenter (MVP)

18

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)

19

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 Entity Framework)

Podatkovna baza (angl. “Data Storage and Management”)

• Fizično shranjevanja podatkov• SQL Server, Oracle, …

21

Fizična arhitektura

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

23

Eno-nivojska fizična arhitektura

24

Interface

Interface ControlBusiness Logic

Data Access

Data Storage and Management

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 odjemalca25

Dvo-nivojska fizična arhitektura

26

Interface

Interface ControlBusiness Logic

Data Access

Data Storage and Management

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

27

Tri-nivojska fizična arhitektura – pametni odjemalec

28

Interface

Interface ControlBusiness Logic

Business Logic

Data Access

Data Storage and Management

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

29

Tri-nivojska fizična arhitektura – spletni odjemalec

30

Interface

Interface ControlBusiness Logic

Data Access

Data Storage and Management

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

31

Štiri-nivojska fizična arhitektura – spletni odjemalec

32

Interface

Interface ControlBusiness Logic

Business Logic

Data Access

Data Storage and Management

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

33

Tri-nivojska fizična arhitektura – spletni odjemalec

34

Interface

Data Storage and ManagementInterface Control

Business Logic

Data Access

Interface ControlBusiness Logic

Data Access

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

35

Porazdeljenost poslovne logike

Težave upravljanja s poslovno logiko

• Podvajanje kode• Sinhronizacija podvojene kode• Vzdrževanje• Preglednost• Rešitev: centraliziranost• Vendar: kje, kako ?

37

Potencialne lokacije poslovne logike

38

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

39

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 validation controls, ASP.NET MVC

DataAnnotations delno rešujejo ta problem

40

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

41

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

42

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

43

Ogrodje CSLA .NET

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)

45

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, Web Forms, ASP.NET MVC, Silverlight, WP7)

• Shranjevanje objektov v podatkovno bazo in pridobivanje iz nje

• Lastna avtentikacija• Razširljivost

46

Stereotipi objektov

• Editable root• Editable child• Editable, “switchable” (i.e., root or child)

object• Editable root collection• Editable child collection

47

Stereotipi objektov

• Read-only root• Read-only root collection• Read-only child• Read-only child collection

48

Stereotipi objektov

• Command object• Name/value list• Dynamic editable list• Dynamic editable root• Criteria

49

Osnovna terminologijaTerm Definition

Object graph One or more objects that reference each other

Root object An object that can be directly retrieved from the database; each objectgraph has exactly one root object

Child object An object that is only retrieved from the database as part of anotherobject (its parent)

Parent object An object that contains child objects (a parent may also be a root)

Editable object An object that implements public read-write properties, or methods thatallow manipulation of data; editable objects can be retrieved and savedto the database; these may be root, parent, or child objects

50

Osnovna terminologijaTerm Definition

Read-only object An object that implements only read-only properties and does not exposemethods that allow manipulation of data; read-only objects can be retrievedfrom the database but not saved; these may be root, parent, or child objects

Collection or list An object that contains other objects; may be editable or read-only; maybe a root or child, but is always a parent

Criteria object An object that contains criteria or key information necessary to identifyand create, retrieve, or delete another object

51

Zaključek

• Csla - ogrodje za implementacijo poslovnega nivoja

• Mobilni poslovni objekti• Odprtokodna rešitev (zastonj, izvorna koda,

prilagodljivost)• Dobra podpora (knjige, forum, primeri

uporabe)• Dolgoletna tradicija – 15 let• Redne posodobitve

52

Hvala