blogs.ASPItalia.com

Chi si ricorda dei DataSet?

Stefano Mostarda — Wed, 08 Oct 2008 20:04:38 GMT

Mi ricordo le prime demo che ho visto riguardo al .NET. Per l'accesso ai dati il DataSet sembrava l'autentica panacea per tutti i mali. A distanza di ormai 7 anni (un'infinit� in termini informatici), i DataSet sono diventati il male impersonificato.

Fondamentalmente questo � quanto di meglio potesse accadere per certi tipi di applicazioni, ma parliamoci chiaro, in Italia si fanno una miriade di piccole-medie applicazioni che non hanno alcuna complessit� e che quindi non trarrebbero vantaggio alcuno dall'uso di un bel domain model con un datalayer che persiste tramite ORM o a mano. In questi casi i DataSet non sono solo la linea pi� veloce, ma anche quella pi� giusta. Se una piccola applicazione � pagata poco o necessit� di essere sviluppata in poco tempo, i DataSet offrono quella velocit� di sviluppo e semplicit� di apprendimento che un'applicazione con domain model non offre.

Insomma tutto questo discorso per dire che per la voglia di sfighettare, si finisce spesso per costruire dei castelli quando basterebbe un appartamento da 50Mq. Ho visto un'applicazione scritta con domain model che gestisce solo 4/5 entit� e richiede quindi almeno il doppio del codice rispetto al dataset. Per carit�, l'applicazione � performante e bella da vedere, ma con i dataset la si faceva ancora in quasi met� tempo e senza grandi sforzi. La domanda interessante e che quando ho chiesto il perch� di questa scelta la risposta � stata: "i dataset sono il male, fare un tree tier aiuta a mantenere tutto pulito". Ineccepibile, se non fosse che per finire l'applicazione ci hanno messo 5 giorni in pi� in 2 persone.

Il consiglio � sempre lo stesso: fidatevi ancora dei dataset. Non hanno un campo di applicazione ampio, ma ce l'hanno e forse potrebbe essere proprio il vostro :D.

Stay tuned...

Tags: ADO.NET, Architettura, ORM, Pattern

Continua a leggere Chi si ricorda dei DataSet?.

Caching nel DataLayer

Stefano Mostarda — Mon, 29 Jan 2007 18:49:00 GMT

Quando si parla di velocit� di acesso ai dati, nulla � pi� veloce che non accedere al db, ma recuperare i dati dalla memoria.

E'�arrivato il momento di fare in modo che i dati nel mio datalayer vengano messi in cache. Quando leggo un record, se questo rispetta certe regole lo metto in cache e da li lo recupero.�Il problema �: se non posso sincronizzarlo con il db tramite SqlCacheDependency (ad esempio perch� non uso SqlServer2005) ed ho bisogno di dati quasi sempre aggiornati (questo implica che non posso usare nemmeno la seconda forma di SqlCacheDependency perch� troppo pesante), come sincronizzo il tutto? La prima risposta che mi sono dato � che semplicemente da codice rimuovo l'elemento dalla cache.

Ma quando ci si trova in ambienti in Server Farm con�due o pi��macchine in cluster? Rimuovere l'oggetto non basta poich� verrebbe rimosso da una sola macchina e rimarrebbe inalterato nelle altre. Un meccanismo per sincronizzare la cache�(tipo la Session) non esiste e questo � un bene. La cache deve essere solo veloce.

Tuttavia, non voglio rinunciare alle comodit� della cache ed a questo punto ho avuto una specie di illuminazione. Bisogna semplicemente�escogitare un metodo per mandare messaggi da un server all'altro per segnalare che un dato � diventato obsoleto e va eliminato.

Visto che sviluppo solo in 2.0 perch� non usare WCF? L'idea � semplice, su una macchina si aggiorna un dato in cache, questo dato viene eliminato e tramite un callback predefinito viene inviato un messaggio ad un servizio che si occupa di smistarlo alle altre macchine. Queste�lo ricevono e aggiornano la propria cache. In questo modo posso aggiungere tutte le macchine che voglio e stare tranquillo che il messaggio verr� recapitato� a tutte grazie alle feature di WCF. Inoltre il traffico e le performance�sono�ottimi perch� ci� che viaggia � un semplice messaggio con una stringa messi in formato binario quindi ottimizzatissimo. L'unica cosa che mi lascia l'amaro in bocca � stata l'impossibilit� di realizzare la cosa in P2P per via di alcune limitazioni di WCF. al prossimo summit non mancher� di chiedere lumi in tal senso :).

Tutto questo sar� materia di un articolo futuro (visto il mix non so ancora se su ASPItalia o WINFXItalia) quindi prima o poi vedrete anche il codice (che non fa mai male)

Tags: .NET Framework 3.0, Architettura, ASP.NET, Cache, Windows Communication Foundation

Continua a leggere Caching nel DataLayer.

Collection generiche come proprietà

Stefano Mostarda — Sun, 08 Oct 2006 22:51:00 GMT

Tempo fa stavo realizzando un primo prototipo in .NET 2.0 e la cosa che mi piaceva molto era l'utilizzo di collection generiche che mi evitavano di dover creare una classe specifica per ogni tipo di collection. Questo significa che nelle mie classi avevo propriet� di tipo List<Classe>.

All'inizio la cosa non era male, meno codice, meno classi, ma la sintassi dopo un p� ne risentiva e soprattutto mi sono accorto che ne risentiva anche la leggibilit�. Certo, List<Classe> e ClasseCollection non sono molto diverse a prima vista, ma se devo fare un metodo di ricerca specifico? E se devo fare dei sort complessi? Le collezioni generiche unite a comparer generici aiutano molto, ma alla fine spargerli nel codice peggiorava leggibilit� e manutenibilit�.

Da quel momento ho capito che le classi collection vanno create sempre facendole derivare da List<Classe> per risparmiare codice e creando metodi di ricerca, sort, etc specifici per ogni collection. Al loro interno, le collection eseguono i comandi utilizzando i metodi generici quindi il guadagno in termini di presazioni � poco. ma incapsulando il codice in questo modo si ha la potenza, la tipizzazione e le prestazioni delle collection generiche mantenendo anche la mentalit� di sviluppo del modello pre-generics.

Stay tuned...

Tags: Architettura, Pattern

Continua a leggere Collection generiche come proprietà.

Come mi piace implementare il pattern Identity Map

Stefano Mostarda — Sun, 17 Sep 2006 12:13:00 GMT

L'Identity Map � uno dei pattern pi� importanti perch� permette di avere in memoria una sola istanza di un'oggetto per ogni sessione. Questo � fondamentale perch� se si hanno 2 versioni di uno stesso oggetto recuperate dal db, queste possono essere potenzialmente diverse causado non pochi problemi.

Nel mio framework, ho introdotto questo pattern da poco per via dei problemi avuti in passato ed ho optato per un'implementazione che � un p� arzigogolata, ma mi sembra essere flessibile e completa. Alcuni reputano che questo Pattern appartenga allo strato di business, ma trattandosi di recupero dati preferisco mantenerlo nello strato dati.

Innanzitutto, ho creato un attributo (KeyAttribute) che serve per decorare le classi di dominio identificando quali sono le propriet� chiave. Ce ne possono essere anche pi� di uno come nei casi in cui si identifica una persona per l'Id preso dal db o per il Codice Fiscale o la parita IVA.
Successivamente, ho creato una classe che contiene una lista degli oggetti letti dal db ed un metodo che gestisce la ricerca. Questo metodo accetta in input la query, il tipo di oggetto che si sta cercando (tramite generic), la chiave ed i valori della chiave in base al quale si vuole verificare se l'oggetto � gi� in memoria, ed un delegate che identifica quale metodo deve essere invocato per eseguire il mapping tra il datareader restituito dalla query e l'oggetto da creare (potevo usare uno strategy, ma questi metodi preferisco tenerli statici visto che non hanno bisogno di stato).
Nel metodo, viene ispezonata la classe dell'oggetto da recuperare alla ricerca dell'attributo il cui nome corrisponda alla chiave passata in input. Una volta trovato l'attributo, si recuperano le propriet� che questo referenzia e si cerca nella lista degli oggetti se ne esiste uno di quel tipo e con le propriet� trovate che abbiano i valori passati in input al metodo. In caso affermativo viene restituito l'oggetto presente nella lista, altrimenti si esegue la query e viene invocato il delegate per costruire l'oggetto che viene infine inserito nella lista e poi restituito.
Lo storage della lista � stato un nodo che ho chiarito all'ultimo, se mi trovo in un'applicazione web allora viene usato il contesto della richiesta, nel caso di un'applicazione windows utilizzo una variabile statica. Per ora questo codice � cablato, ma confido al pi� presto di buttare gi� un'interfaccia cos�da rendere il meccanismo pluggabile (non si sa mai che esigenze si possono avere nel futuro).

Stay tuned...

Tags: Architettura, Database, Pattern

Continua a leggere Come mi piace implementare il pattern Identity Map.

I pattern che uso in genere

Stefano Mostarda — Tue, 24 Jan 2006 23:38:00 GMT

Nella mia carriera di creatore di software penso di aver approcciato al mondo dei pattern in maniera un p� tardiva: solo un paio di anni fa. Da allora il libro che ho letto riletto e controriletto fino a consumarlo con gli occhi � ovviamente il PEAA del sommo Martin Fowler. Questo libro si basa in parte anche sui pattern GoF il cui libro � stato consumato poco meno.�

In questi anni di prove e controprove ho storpiato, rivisisto, migliorato, anche provato ad inventare soluzioni che potessero diventare dei pattern, come l'evento per il lazy loading seguito da molti leggendone qua e la per vari blog :D.

Dopo un paio di anni di lavoro, sono arrivato al punto in cui ho creato un mio framework che utilizzo per tutti i progetti che sviluppo. Questo framework sfrutta i seguenti pattern:

Abstract Factory per l'indipendenza dal db e poter scrivere i test per la BLL e il DomainModel

Unit Of Work per gestire gli aggiornamenti sul db

Optimistic Offline Lock per getire gli aggiornamenti concorrenti all'interno di uno UnitOfWork

Lazy Load per caricare le collection separatamente dalle classi che le contengono

Eager Loading per caricare le collection contestualmente alle classi che le contengono

DomainModel per il modello delle classi

DataMapper per interfacciarsi con il db

Singleton per avere una classe che gestisce i settings dell'applicazione (sostituita da un build provider per asp.net 2.0)

Registry per accedere alle istanze delle classi singleton.

Questi sono i pattern presenti nel mio framework, a questi se ne�aggiungono altri a seconda delle esigenze dell'applicazione. Conto comunque di parlarne nel tempo di come li ho implementati. E voi quali pattern usate in genere?

Stay tuned...

Tags: Pattern

Continua a leggere I pattern che uso in genere.

Factory Pattern e Generics per l'astrazione dal db

Stefano Mostarda — Thu, 15 Sep 2005 23:29:00 GMT

Non c'� dubbio che una delle tecniche migliori,�anzi la migliore, per ottenere un'astrazione dalla base dati � implementare un Factory Pattern.�Con la�versione 1.x del framework,�siamo obbligati�a creare un metodo per ogni classe del DataLayer che dobbiamo istanziare, quindi se abbiamo 50 classi di datalayer, ci sara una classe�con 50 metodi, o 50 classi con un metodo. Se si vuole risparmiare, si fa un metodo che accetta l'interfaccia che la classe da creare implementa (passandola come object) e che�poi torna la classe�come object. Lo svantaggio sta nel fatto di perdere la tipizzazione.�Tutto questo perch� nella versione 1.x non possiamo definire dinamicamente il tipo di ritorno di una funzione.

Ecco che l'introduzione dei Generics nella versione 2.0�migliora drasticamente il�codice.�Nei miei progetti ho un file di configurazione che mappa le interfacce con la classe reale e con l'assembly che la contiene (a volte ho un datalayer spalmato in diversi assembly per particolari esigenze) e altre informazioni. A questo punto mi basta�invocare il metodo GetClass della classe Factory�specificando l'interfaccia come Generic. Leggendo il file di configurazione viene trovata la classe associata, viene istanziata e tornata ottenendo�cos� lo strong typing caratteristico dei�Generics.

internal static T GetClass<T>() { ��XmlDocument d = new XmlDocument(); ��d.Load("d:\\MyApp\\db.config"); ��string interfaceName = typeof(T).FullName; ��foreach (XmlNode n in d.SelectNodes("Maps/Map")) ��{ ��if (n.Attributes["interface"].Value == interfaceName) � ��{ �� Type type = Type.GetType(n.Attributes["class"].Value); �� object o = Activator.CreateInstance(type, true); � ��return (T)o; ��} ��}

��throw new DALException("Interface not found in the mapper file");
��}
}

Il metodo non � nella sua versione completa, ma � comunque una base di partenza.

Stay tuned...

Tags: Object Oriented Programming, Pattern

Continua a leggere Factory Pattern e Generics per l'astrazione dal db.