premessa: Ai recenti Community Days mi sono ritrovato più volte a parlare con tante persone, sullo stato attuale di Linq to SQL e del successivo Entity Framework,e mi ricordo di aver detto a più persone che un post che avevo letto settimane fa proprio da un membro del team di EF mi aveva lasciato di sasso.
Stamattina ho cercato per curiosità quel post e l'ho trovato. Pochi minuti fa ne stavamo parlando in chat con il pres, e lui mi ha appena anticipato con questo post (ps: grande come sempre!).
Divio con voi alcune riflessioni.
Metto l'accento su qualche passo (del post originale di Simmons):
Initially I thought that some of the requests for *complete* persistence ignorance were the products just of dogma rather than fully informed and reasoned arguments, but when so many people give such passionate feedback it was clear that I needed to investigate more before I could claim to have any sort of an informed opinion.
Cioè fatemi capire...uno del team, apprende da fonti esterne che c'è una "necessità" di Persistenza Trasparente (a.k.a Persistence Ignorance)?
Mi viene da dire...e dove ha vissuto negli ultimi 5 anni?
Mi viene ancora da dire....ma un ORM lo hai mai utilizzato?
ancora...
The product of my research is that I am now truly convinced of the importance of complete persistence ignorance for some scenarios.
Mi pare assolutamente normale. Il team di Linq to SQL risolve questa cosa tranquillamente a seconda del tipo di oggetto che viene dato in pasto al DataContext. NHibernate può cambiare tutta la strategia di tracking con un interceptor. Quello che è *anormale* è che quelli del team di EF pensino a problemi del genere a pochi mesi del rilascio. Negli ultimi anni chi ha mai pensato al *big design* della loro soluzione? IHMO E' sconvolgente.
ancora...
To make this more concrete, we have identified 4 elements of the existing entity framework design which block persistence ignorance. That is, 4 ways in which entities are currently required to have knowledge of the framework:
- They must store a copy of an EntityKey.
- They must provide change tracking notifications through a prescriptive interface.
- They must be decorated with a series of attributes which provide additional metadata.
- If they participate in relationships, the requirements are even more stringent as indicated by the requirement to implement the interface IEntityWithRelationships.
The first two requirements are enforced with the IEntity interface and must be addressed if we are to enable persistence ignorance at any point in the future. At the same time each of these has significant performance implications. Choosing not to store EntityKeys on the entities, for instance, means that navigating from an entity to the ObjectStateEntry which matches it either requires a brute-force search of the ObjectStateManager or for the ObjectStateManager to maintain a dictionary mapping from CLR reference to ObjectStateEntry which is a significnat expense.
Che esista una key nella entity è una regola di ferro imposta dal pattern Identity Field. Serve a far sopravvivere una entity a più contesti di persistenza e non solo a sincronizzare una entity sul database. L'ObjectStateManager di cui si parla nell'articolo potrebbe tenere una mappa di chiavi entity, ma questa mappa non sopravviverebbe a scenari disconnessi. Questa è l'ennesima conferma che non esiste una guidance architetturale su come si debba usare il contesto di persistenza. Può essere che gli vengano i dubbi sull'unica cosa da non toccare? Consiglio di vedere le best practices in fondo alla reference di NHibernate.
e ancora...
So, to sum it all up, message received: persistance ignorance is needed, and we're now working to deliver it.
E meno male. Ma dico io, non sono neanche andati a vedere come stavano lavorando i cugini di Linq 2 SQL? Ne ho parlato alla mia sessione: in quest'ultimo, anche senza utilizzare EntitySet e EntityRef, non ci sono legami a API specifiche e attualmente tutto funziona regolarmente secondo un principio di Persistenza Trasperente (con perdite di feature...ma alla fine un accrocchio si trova). E questi di EF che invece dovevano fare (a detta loro) lo *scenario enterprise* ci stanno pensando adesso? Meglio tardi che mai.
E allora veramente come dice Andrea, comprate Gavin King (il papà di Hibernate).
Ma compratelo veramente...
Ultima cosa: sembra una allegoria ma è vera, queste discussioni arrivano dopo che lui (e forse qualche altro) hanno studiato un po di Domain Driven Design dal libro di Eric Evans (ce l'ho da due anni e mezzo)...si evince da altri post sul suo blog. Non ho parole.
DELUSIONE
PS: non ce l'ho mica fatta a contare fino a 10-mila-...