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 @ venerdì 23 giugno 2006 19:28

Print

Comments on this entry:

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

Left by Roberto Messora at 23/06/2006 19:34
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 29/06/2006 18:21
Gravatar
Stò lavorando ad un progetto di nn elevata criticità ma abbastanza articolato. Al solito è nato il problema...

Your comment:



 (will not be displayed)


 
 
Please add 5 and 3 and type the answer here:
 

Live Comment Preview:

 
«novembre»
domlunmarmergiovensab
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567