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:

posted @ Friday, June 23, 2006 4:28 PM

Print

Comments on this entry:

# Re: ADO .NET 3.0 Entity Framework: DLINQ Strikes Back

Left by Roberto Messora at 6/23/2006 4:34 PM
Gravatar
su con la vita, mettila così: non hai mai lavorato con gli ArcObjects e i geodatabase.
Ritieniti _molto_ fortunato...

Saluti

# ORM: tra i tanti...

Left by Mighell's blog at 6/29/2006 3:21 PM
Gravatar
Stò lavorando ad un progetto di nn elevata criticità ma abbastanza articolato. Al solito è nato il problema...
Comments have been closed on this topic.
«May»
SunMonTueWedThuFriSat
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678