MesBlog

Thinking in sharp architectures
posts - 179, comments - 436, trackbacks - 150

EF: I nodi alla fine vengono sempre al pettine

Julie Lerman, che sta scrivendo un libro per O'Reilly circa Entity Frameowrk, piano piano si sta rendendo conto delle "stranezze" (chiamiamole così) in cui ci si imbatte utilizzando EF. Chiariamo una cosa, EF è un framework con cui si può lavorare, tanto che lo sto utilizzando per un progetto reale, ma è suscettibile di critica, soprattutto quando ci si rende conto che chi lo ha progettato è chiaro che non avesse in mente che cosa sia esattamente un ORM.

Per farla breve si è resa conto che probabilmente non sarebbe stata la cosa più furba del mondo esporre alla UI il concetto di EntityKey e EntityReference, di conseguenza è stata "costretta" (da EF ovviamente) a scrivere una tonnellata di codice ripetitivo per incapsulare nelle enitity stesse la gestione degli stessi (ed utilizzare il termine "sick" la dice lunga...).

Beata ignoranza! Nel senso di Persistence Ignorance, che ella scopre essere "tanto cara e tanto onesta" (cit.).
Mi lascia abbastanza scioccato il fatto che tratti l'argomento come una "issue" saltata fuori durante la stesura di codice d'esempio per il libro, come se avesse trovato un fungo velenoso durante una passeggiata nel bosco, quando un minimo di conoscenza della teoria di base degli ORM e appunto della Persistence Ignorance, gli avrebbe suggerito a priori che lo scenario che stava cercando di risolvere si sarebbe tramutato in un incubo (tanto che io ho deciso di non risolverlo, perchè context is king).

Due considerazioni a latere.
Pensiamoci tutti due volte quando siamo tentati di dire che i patterns e compagnia cantante sono solo teoremi dei massimi sistemi, che prima o poi ci troveremo a combattere contro codice di produzione "reale" in cui uno dei tanti vituperati pattern ci avrebbe salvato la vita se correttamente implementato (e quindi speriamo che il team di EF abbia capito la lezione, e che V2 sia in realtà la V1 di un prodotto che di uguale avrà solo il nome).
Rimango basito e dubbioso quando scopro che ci sono persone che di ORM e architetture che ne fanno uso (nella fattispecie basate su Domain Model) non ne sanno quasi nulla e che vengono scelte per scrivere libri inerenti: Julie lerman e David Sceppa, con due libri su EF in uscita (O'Reilly e Microsoft Press), ne sono un esempio lampante.

Print | posted on Sunday, August 31, 2008 9:42 AM |

Feedback

Gravatar

# re: EF: I nodi alla fine vengono sempre al pettine

David Sceppa e Julie Lerman "vendono"... altri un po' meno... Market is the king
8/31/2008 11:20 AM | Lorenzo Barbieri
Gravatar

# Re: EF: I nodi alla fine vengono sempre al pettine

Lorenzo, basterebbe, per vivere felici, abbinare uno che vende e che cmq mediamente sa, ad uno che di quel particolare campo sa davvero tutto.
salvi capra e cavoli: vendi perchè il frontman è marketing e ci fai pure bella figura
meglio di così...
saluti
Roberto
Gravatar

# re: EF: I nodi alla fine vengono sempre al pettine

Lorenzo - così come hai detto - è come se leggessi in genere chi scrive il più dei libri sono dei giullari che sanno far divertire ma dai quali si può imparare solo qualche magheggio da circo di paese...
8/31/2008 7:56 PM | M.rkino
Gravatar

# Re: EF: I nodi alla fine vengono sempre al pettine

non ho ancora lavorato con EF, mi incuriosisce ma per adesso non mi serve.
Cmq, sento spesso osservazioni & commenti poco felici su questo fw, come il tuo...
vedremo...
9/1/2008 12:25 PM | Igor Damiani
Gravatar

# re: EF: I nodi alla fine vengono sempre al pettine

Luca, ho marginalmente partecipato al brain storming con Roberto per fare esattamente qllo che hai descritto. Incapsulare EF - come uso fare per le parti tecnologiche - è troppo oneroso e ci si deve arrendere a trattarelo come parte del sistema... infrastruttura. Sad but true.
9/1/2008 3:41 PM | M.rkino
Gravatar

# Re: EF: I nodi alla fine vengono sempre al pettine

Luca, non voglio sembrare polemico, ma il fatto che tu conosca dei team che fanno ciò che affermi non significa che debba necessariamente essere fatto così.
semplicemente non sappiamo quali siano le condizioni al contorno che li hanno portati a incapsulare librerie di terze parti, perchè quello che per te è un vincolo di ristrettezza di tempi/costi per me potrebbe non esserlo e viceversa.
Inoltre sono sempre più convinto che sovraigegnerizzare un'architettura sia dannoso per quanto riguarda la scalabilità, ma anche per quanto riguarda la semplicità del design e l'approccio del design dal basso. voglio dire che se partiamo dal basso, è difficile intravedere la big picture secondo la quale una libreria deve essere incapsulata in un wrapper design-friendly, soprattutto se questa è complessa ed articolata come EF: capirne le sfumature necessità di un big design upfront che va contro tutto ciò che è agile, in caso contrario l'effort di refactoring del wrapper potrebbe diventare insostenibile e generare risciritture di ampie porzioni di codice.
Context is king, design is prince, at most.

saluti
Roberto
Gravatar

# re: EF: I nodi alla fine vengono sempre al pettine

Luca senza fare polememica non sono mai partito dal presupposto che "non sia possibile farlo "... semplicemente con i vincoli costi/tempi che si avevamo la nostra unica scelta è stata pensare - scelta forte - a EF come infrastruttura. A questo punto credo che si dovrebbe mettere sul piatto della bilancia - non è mia intenzione farlo - quali sono i rispettivi vincoli di tempo e costi... per il poco che ho visto senza voler dire ne bene ne male di EF è chiaro che MS non ha nemmeno pernsato che EF potesse essere usato incapsulato: troppe restrizione di utilizzo.
9/1/2008 4:41 PM | M.rkino
Gravatar

# Re: EF: I nodi alla fine vengono sempre al pettine

Luca, a mio modo di vedere ritorniamo sempre al punto di partenza, ovvero i vincoli di contesto. Io credo fermamente che l'approccio al problema che citi non possa essere preso come modello buono per tutte le stagioni.
ribadisco per l'ennesima volta. context is king. e questo significa che è il contesto che dirige in prima battuta l'approccio allo sviluppo di un progetto, quindi anche al design che è una parte del tutto, ma non può essere il mainstream di un intero progetto.
da parte nostra il contributo deve essere quello di avere a disposizione il maggior numero di conoscenze ed il maggior numero di strumenti, ma senza pensare che questi debbano per forza di cose condizionarci.
il nostro lavoro non è quello di imporre una visione, ma quello di risolvere problemi calati in un contesto operativo e di stakeholders, di vincoli e interazioni, scegliendo ciò che è meglio per il successo del progetto stesso e di coloro he ce lo hanno commissionato.
nel mio caso attuale, la scelta di design è stata quella di definire un'interfaccia leggera di DataContext al solo fine della testability (mockabile quindi), prendendo una decisione ponderata (dopo aver impiegato una settimana a verificare se EF fosse "wrappabile", passami il termine sbrigativo) in base al fatto che la questione sarebbe stata una inutile sovraingegnerizzazione, sia per quanto riguarda le prestazioni generali, sia per quanto riguarda la complessità del framework (quest'ultimo vincolo, esogeno per noi, avrebbe imposto un effort maggiorato di lavoro che non era minimamente compatibile con altri vincoli come quelli di tempo e investimento economico).
questo processo decisionale è quello che io reputo decisamente il più corretto a livello metodologico per quelle che sono le peculiarità della nostra professione.
saluti
Roberto
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET