Mr Roberto Faiga a parte (a proposito: tornerà in Italia o rimarrà qui?), il vero tormentone qui a L.A. ha un nome ben preciso: LINQ. Oltre ai suoi "gusti" dLINQ e xLINQ, ovviamente. Dopo una notte di riflessioni e confronti con i miei compagni di viaggio, ho assistito alla sessione di Luca Bolognese, della cui disponibilità ho approfittato per torgliermi alcuni dubbi mediante qualche domanda mirata e forse anche un po' cattivella. Innanzitutto, i miei complimenti a Luca, perchè la sua sessione è stata divertente e ben bilanciata. Lo ringrazio anche per la sincerità con la quale dal palco ha detto: "Se state cercando un ORM full-featured, non guardate a dLINQ. dLINQ vuole essere semplice by design". Ecco quindi la mia opinione dopo: 2 sessioni, 2 chiacchierate con Luca e 2 notti di riflessioni:
- Se la vostra applicazione deve essere db-independent, *non* potrete usare dLINQ perchè l'idea di Microsoft è che ad essere annotato sia il domain model, e non un modello ad esclusivo uso e consumo del DAL e in esso incapsulato. Questo significa che il domain model è direttamente accoppiato con lo schema fisico, e non è possibile avere mapping specifici per DAL differenti (il che è anche comprensibile, se si pensa che dLINQ lavora *solo* in abbinamento a SQL Server). Essendo basata su attributi, la modifica del mapping richiede ovviamente la ricompilazione del domain model.
- Per poter persistere delle modifiche, dLINQ richiede che esse siano effettuate direttamente sugli oggetti da esso estratti. Questo significa che dobbiamo trovare un modo per mantenere in memoria le istanze delle business entity restituite da dLINQ, al fine di modificarle e girarle nuovamente all'ORM (ma dobbiamo proprio chiamarlo così?). Questo significa che se volete utilizzarlo in applicazioni web form, dovrete imbottire la Session con gli oggetti restituiti da dLINQ. Oltretutto, poichè gli oggetti ragionano in termini di "identità" e non di "valore", dovrete anche usare le Session "in-process" e quindi addio pubblicazione della applicazione in una web farm. A mia domanda esplicita, Luca ammette che quello presentato (applicazione ASP.NET di tipo web form) non è effettuvamente uno scenario attualmente gestito.
- L'affermazione "Una classe==una tabella" è un dogma: scordiamoci quindi di gestire scenari nei quali la nostra business entity debba veder persistito il suo stato su tabelle differenti.
Non mancano le note positive (es: la gestione della concorrenza e delle transazioni è convincente, il mapping lavora anche sui membri privati quindi è possibile differenziare la struttura del modello da quella dello schema dati), ma IMHO i difetti sono strutturali e limitano l'introduzione della tecnologia in scenari enterprise. Per carità, siamo solo all'inizio del percorso e molto potrà cambiare, ma "Se il buon giorno si vede dal mattino" ...Beh, io ho l'ombrello già pronto . Meno male che LINQ!=dLINQ (o LINQ<>dLINQ, se usate VB): LINQ è una figata, per il mapping... C'è sempre NHibernate :-)