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