Real World data access layers
DataSet vs. Custom entities
Pierre Greborio
Software Architect – PEWay SrL
Microsoft MVP – Solutions Architect
Agenda




Architetture di riferimento
Tecniche di accesso al RDBMS
Business objects
Metodi di accesso al dato persistente


Autonomous business object
Data mapper
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
…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
I layer principali

Presentazione


Domain (o anche business logic)


Fornitura di servizi (facade), visualizzazione di
informazioni (UI), comandi della shell, ecc.
Logica applicativa (è il vero cuore del
sistema)
Data Source

Comunicazione con i database, sistemi di
messaggistica, applicazioni esterne, ecc.
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
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
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)
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
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 !!
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 !
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, …
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 
DAL personale


Sviluppare l’accesso al dato in base alle
proprie esigenze
Considerare sempre lo scenario di
riferimento (applicazione monolitica, clientserver, distribuita, su più database
eterogenei, ecc.)
Designer di VS.NET



Logica Drag&Drop
E’ perfetto per la prototipazione
Attenzione, crea un monolite !
Business Objects
La tecnologia usata può influenzare il DAL
 Classi fortemente tipizzate
 DataSet
 DataSet tipizzati
 XML
Demo
Business Object
Persona
Codice
Nome
Cognome
DataDiNascita
CodiceFiscale
Classi tipizzate
Pro
 Astrazione
 Performance
 Serializzazione
 Manutenzione
 Tipizzazione forte
Contro
 Collezzioni
tipizzate
complesse
 Supporto alla
concorrenza
 Integrazione
limitata
DataSet
Pro
 Funzionalità
native
 Supporto alle
collezioni
 Manutenzione
 Serializzazione
 Concorrenza
Contro
 Non supportano la
singola istanza
 Non supportano il
new
 Performance
 Tipizzazione
debole
DataSet tipizzato
Pro
 Funzionalità
native
 Supporto alle
collezioni
 Concorrenza
 Serializzazione
 Tipizzazione forte
Contro
 Non supportano la
singola istanza
 Non supportano il
new
 Performance
XML
Pro
 Integrazione
 Serializzazione
 Accoppiamento
flessibile
Contro
 Tipizzazione
debole
 Performance
 Difficile da
manutenere
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
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
Demo
Active Record
CREATE TABLE Persone
(
)
[ID]
INT IDENTITY PRIMARY KEY,
[Nome]
VARCHAR(50) NULL,
[Cognome]
VARCHAR(50) NOT NULL,
[DataDiNascita]
DATETIME NULL,
[CodiceFiscale]
CHAR(16) NULL
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
Mapper Patterns



Data Mapper
Table Data Gateway
Row Data Gateway
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
Persona
PersonaMapper
Codice
Crea()
Nome
Modifica()
Cognome
Cancella()
DataDiNascita
Leggi()
CodiceFiscale
Table Data Gateway



La TDG contiene tuttale la logica di
accesso al DB
Solitamente è senza stato
Può mappare più entità di business
Persona
PersonaGateway
Codice
Crea(Codice, Nome, …)
Nome
Modifica(Codice, Nome,…)
Cognome
Cancella(Codice)
DataDiNascita
Leggi(Codice)
CodiceFiscale
Row Data Gateway


E’ un’estensione del Data Table Gateway
Da usare quando la logica di ricerca
diventa complessa
PersonaFinder
Leggi(Codice)
LeggiPerCodiceFiscale(CF)
Persona
LeggiPerCognome(Cognome)
Codice
Nome
Cognome
DataDiNascita
CodiceFiscale
PersonaGateway
Crea(Codice, Nome, …)
Modifica(Codice, Nome,…)
Cancella(Codice)
Classi DB helper

Sono classi general purpose
personalizzate per la persistenza



Factory di connessioni
Conversioni DB type - .NET type
Factory di comandi
Data Access Application
Block
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/daab.asp
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
Domande ?
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
Scarica

Real World data access layers DataSet vs. Custom entities