In questi giorni sto spulciando un pochino questo ORM e fino ad ora le mie impressioni sono senz'altro positive; LINQ to SQL, a mio modo di vedere, è un prodotto che ha dalla sua un'estrema produttività, almeno per un paio di ragioni:
- Intanto l'ottima integrazione con il designer di Visual Studio, che si interfaccia con la base dati e ci consente di modellare il dominio applicativo veramente in brevissimo tempo: la comodità del designer del DataSet applicata ad un Domain Model + ORM, praticamente il mio sogno
- La semplicità e la naturalezza di LINQ come linguaggio di interrogazione, che ci consente di comporre (già, comporre, magari ne parlerò in un altro post) query complesse in maniera estremamente intuitiva e soprattutto strong typed (anche se alle volte si è costretti a smanettare con le lambda expression).
Ora.. è vero che il dominio viene "sporcato" dagli attributes, che c'è EntitySet per le collection e non una semplice interfaccia e che NHibernate rullezza, ma il mio pensiero in merito è più o meno "chi se ne frega"
Giuro che non avrei mai pensato di scrivere quel "chi se ne frega" di una riga fa, ma c'è una ragione: credo che LINQ to SQL sia, al giorno d'oggi, una soluzione estremamente valida per tutte quelle applicazioni - e sono tante - che difficilmente vedranno una versione 2.0. Per questa ragione un paragone con NHibernate è un pochino fuorviante e mal posto: il target è diverso, al massimo paragoniamolo ad Active Record e comunque consideriamolo un ORM dall'approccio molto più easy e anche parecchio RAD. Questo giustifica anche il punto 1 in alto, che magari avrà fatto storcere il naso a quanti, come il sottoscritto d'altronde, sono convinti che le entity di dominio vadano modellate a prescindere dallo schema del database.
Ovviamente non è tutto rose e fiori, ci sono aspetti che non mi hanno convinto fino in fondo, ma di questo scriverò (spero di averne il tempo) domani.