...Then love, love will tear us apart... Again

http://www.controlthemovie.com/

UPDATE: Già si sapeva che per la OST i New Order avrebbero (re)interpretato i pezzi dei Joy Division, ora sappiamo che il roster sarà di tutto rispetto. Non fai in tempo a riprenderti dalla colonna sonora di Donnie Darko, ed ecco un'altra "botta": non so se potrei "reggere" l'ascolto di "Heroes"...

ADO .NET Entity Framework: DLINQ Strikes Back

Ok, lo ammetto: mi ero illuso. Pensavo che la Forza avesse fatto il suo corso, sconfitto il Lato Oscuro e che avremmo avuto un ORM incluso nel framework. Pensavo che il significato di "definire il *mio* domain model e realizzarne il mapping verso uno store relazionale in modo non invasivo" fosse abbastanza chiaro. Lette le specifiche, non riesco a pensare che un tool che genera il domain model a partire dallo schema relazionale sia una buona soluzione. Nemmeno se il mapping è estraneo al domain model. E... No, il fatto che le classi siano generate come "parziali" non mitiga affatto il problema. Ripartiamo dalle basi:
  • L'architetto recepisce i requisiti funzionali e li integra con quelli non funzionali
  • Viene prodotto il diagramma dei casi d'uso, comprensivo di descrizione degli stessi
  • Dai casi d'uso viene derivato il diagramma delle classi (o "diagramma di struttura statica", se oggi vi sentite forbiti)
  • Il diagramma delle classi prodotto contiene (anche) il domain model
Bene. Ora ripetiamo insieme: "poichè il domain model l'ho già, come lo mappo sullo store relazionale?". Apparentemente, la risposta è: "Di certo *non* usando ADO.NET 3.0 EF / DLINQ / LINQ to SQL (o come diamine lo volete chiamare)". Ed è un peccato, perchè LINQ è, continuo a pensarlo (e sostenerlo), assolutamente meraviglioso. Poter esprimere nel proprio linguaggio *e* in modo assolutamente type safe qualcosa del genere:
var newSalesPeople = from p in aw.SalesPeople
                                  where p.HireDate > hireDate
                                  orderby p.HireDate, p.FirstName
                                  select new { Name = p.FirstName + " " + p.LastName, HireDate = p.HireDate };
o "addirittura":
var query = from o in dsOrders.SalesOrderHeader
                   join d in dsOrders.SalesOrderDetail
                   on o.SalesOrderID equals d.SalesOrderID
                   where o.OnlineOrderFlag == true
                   select new { o.SalesOrderID, o.OrderDate, d.ProductID, Quantity = d.OrderQty };

Significa (significherebbe) *davvero* rendere le applicazioni in grado di pensare a(gli) oggetti.
Non so se qualcuno lo possa aver notato, ma il mio post di qualche giorno addietro è stato rinominato in "ADO .NET 3.0 Entity Framework: una nuova speranza". A questo punto, spero di poterne scrivere prima o poi uno intitolato: "ADO .NET 3.0 Entity Framework: il ritorno dell'ORM" nel quale parlo di NLINQ, la versione "idiomatica" di NHibernate che, dato il mapping, mi offre il data context che lo abilita a LINQ spazzando via in un colpo solo tanto le brutture del mapping "made in Redmond" quanto quelle di "vorrei ma non posso" HQL. Si, ok... "E poi ti svegli tutto sudato". Verissimo: sono interista, ormai ci sono abituato.

Technorati tags:

«June»
SunMonTueWedThuFriSat
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678