Real World data access layers DataSet vs. Custom entities Pierre Greborio Software Architect – PEWay SrL Microsoft MVP – Solutions Architect.

Presentazione sul tema: "Real World data access layers DataSet vs. Custom entities Pierre Greborio Software Architect – PEWay SrL Microsoft MVP – Solutions Architect."— Transcript della presentazione:

1 Real World data access layers DataSet vs. Custom entities Pierre Greborio Software Architect – PEWay SrL Microsoft MVP – Solutions Architect

2 Agenda Architetture di riferimento Tecniche di accesso al RDBMS Business objects Metodi di accesso al dato persistente Autonomous business object Data mapper

3 Layering E’ una delle tecniche più comuni per separare sistemi software complicati Ogni layer superiore usufruisce dei servizi del layer immediatamente inferiore Il layer inferiore non sa nulla del layer superiore

4 …layering Il layering presenta anche degli svantaggi: E’ suscettibile delle modifiche a cascata se si aggiunge un campo nel database che deve essere visualizzato nella UI Può risultare un decadimento nelle prestazioni il layering presuppone una trasformazione da una rappresentazione ad un’altra

5 I layer principali Presentazione Fornitura di servizi (facade), visualizzazione di informazioni (UI), comandi della shell, ecc. Domain (o anche business logic) Logica applicativa (è il vero cuore del sistema) Data Source Comunicazione con i database, sistemi di messaggistica, applicazioni esterne, ecc.

6 Layer di presentazione Contiene la logica di interazione tra l’utilizzatore ed il software Spazia da un comando shell a un’interfaccia grafica ricca (Windows o Web) Potrebbe essere anche la facciata di un web service

7 Layer di dominio Detto anche Business Layer o Business Logic Include i calcoli basati sui dati di input ed i dati storicizzati Valida tutti i dati che arrivano dalla presentazione

8 Layer di data source Serve a far comunicare l’applicazione con altri sistemi In una applicazione enterprise solitamente questo layer si occupa della persistenza su database relazionale Molto spesso le componenti che si occupano della persistenza si indicano sotto il nome di DAL (Data Access Layer)

9 Componenti DAL Creare record nel database da un BO Leggere record dal DB per generare BO Aggiornare record nel DB in base a modifiche di un BO Cancellare un record nel DB Spesso si parla di CRUD: Create, Read, Update e Delete

10 Layering in pratica Solitamente il layer di dominio nasconde completamente il layer di accesso al dato Capita anche che il layer di presentazione acceda al dato Una soluzione può non essere pura, ma essere migliore in pratica Usare il buon senso è la cosa migliore, se poi non è perfetto…refactoring !!

11 Accedere al RDBMS Uso un ORM Mi scrivo un ORM Mi scrivo una DAL personale Mi basta il designer di Visual Studio.NET Convinco il mio capo a passare a MS Access o Excel !

12 ORM Object Relational Mapping tool Server a mappare il mondo object oriented al mondo del database relazionale Vanno dai generatori di codice ai mapper (XML) puri I più famosi: NHibernate, ORM.NET, EntityBroker, IBatis.NET, NPersist, WilsonORMapper, …

13 ORM custom Ha senso solamente se volete venderlo come prodotto Richiede un grande investimento di risorse Bisogna conoscere molte casistiche Ce ne sono già tanti

14 DAL personale Sviluppare l’accesso al dato in base alle proprie esigenze Considerare sempre lo scenario di riferimento (applicazione monolitica, client- server, distribuita, su più database eterogenei, ecc.)

15 Designer di VS.NET Logica Drag&Drop E’ perfetto per la prototipazione Attenzione, crea un monolite !

16 Business Objects La tecnologia usata può influenzare il DAL Classi fortemente tipizzate DataSet DataSet tipizzati XML

17 Demo Persona Codice Nome Cognome DataDiNascita CodiceFiscale Business Object

18 Classi tipizzate Pro Astrazione Performance Serializzazione Manutenzione Tipizzazione forte Contro Collezzioni tipizzate complesse Supporto alla concorrenza Integrazione limitata

19 DataSet Pro Funzionalità native Supporto alle collezioni Manutenzione Serializzazione Concorrenza Contro Non supportano la singola istanza Non supportano il new Performance Tipizzazione debole

20 DataSet tipizzato Pro Funzionalità native Supporto alle collezioni Concorrenza Serializzazione Tipizzazione forte Contro Non supportano la singola istanza Non supportano il new Performance

21 XML Pro Integrazione Serializzazione Accoppiamento flessibile Contro Tipizzazione debole Performance Difficile da manutenere

22 Metodi di accesso al DB Autonomous business object L’oggetto di business contiene anche i metodi di accesso al dato Pattern: Active record Mappers L’oggetto di business e l’entità nel DB hanno una differente struttura Molte parti dell’oggetto, quali collezioni e ereditarietà, non sono presenti nel DB

23 Active record pattern L’oggetto contiene sia i dati che il comportamento I dati (non tutti) devono essere persistiti sul DB Persona Codice Nome Cognome DataDiNascita CodiceFiscale Insert Update

24 Demo CREATE TABLE Persone ( [ID]INT IDENTITY PRIMARY KEY, [Nome]VARCHAR(50) NULL, [Cognome]VARCHAR(50) NOT NULL, [DataDiNascita]DATETIME NULL, [CodiceFiscale]CHAR(16) NULL ) Active Record

25 Mapper Divisione netta fra il mondo di business ed il mondo della persistenza E’ l’approccio standard degli ORM Ideale per: Astrarre la persistenza Sviluppo in team Unit testing più granulare

26 Mapper Patterns Data Mapper Table Data Gateway Row Data Gateway

27 Data mapper L’oggetto contiene i dati che il comportamento di business I metodi di persistenza stanno in una classe esterna ma si riferiscono sempre alla classe da mappare PersonaMapper Crea() Modifica() Cancella() Leggi() Persona Codice Nome Cognome DataDiNascita CodiceFiscale

28 Table Data Gateway La TDG contiene tuttale la logica di accesso al DB Solitamente è senza stato Può mappare più entità di business PersonaGateway Crea(Codice, Nome, …) Modifica(Codice, Nome,…) Cancella(Codice) Leggi(Codice) Persona Codice Nome Cognome DataDiNascita CodiceFiscale

29 Row Data Gateway E’ un’estensione del Data Table Gateway Da usare quando la logica di ricerca diventa complessa PersonaGateway Crea(Codice, Nome, …) Modifica(Codice, Nome,…) Cancella(Codice) Persona Codice Nome Cognome DataDiNascita CodiceFiscale PersonaFinder Leggi(Codice) LeggiPerCodiceFiscale(CF) LeggiPerCognome(Cognome)

30 Classi DB helper Sono classi general purpose personalizzate per la persistenza Factory di connessioni Conversioni DB type -.NET type Factory di comandi

31 Data Access Application Block http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/daab.asp

32 Considerazioni Il DataSet tipizzato è ottimale per il pattern Active Record Il DataSet è ottimale nelle architetture statefull o nelle lookup in cache Le classi fortemente tipizzate sono molto flessibili e meno soggette ad errori di utilizzo

33 Domande ?

34 Riferimenti MSDN Data Patterns http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/dp.asp MSDN Data Access Architecture Guide http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp MSDN Data Access Application Block http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/daab.asp Patterns of Enterprise Application Architecture