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

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, client- server, 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 Persona Codice Nome Cognome DataDiNascita CodiceFiscale Business Object

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

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 PersonaMapper Crea() Modifica() Cancella() Leggi() Persona Codice Nome Cognome DataDiNascita CodiceFiscale

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

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)

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

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 MSDN Data Access Architecture Guide MSDN Data Access Application Block Patterns of Enterprise Application Architecture