(luKa)

Ergo Luca, se wrappare Entity Framework rallenta il rilascio di funzionalità utili al cliente, è uno spreco...
saluti
Roberto

Gestire correttamente le transazioni è un requisito, in quanto necessario al buon funzionamento dell'applicazione. Insomma è qualcosa che gli stakeholders si aspettano dal prodotto software. Astrarre EF, a meno che non venga richiesto esplicitamente, non è un requisito.

E' sicuramente possibile astrarre EF, ma è necessario? E' probabile che la prossima versione di EF sia retrocompatibile. Anche se non lo fosse, potrebbero esistere dei tool di conversione già pronti che renderebbo la migrazione più economica che progettare ora un "wrapper" e addattarlo in futuro alla nuova versione. Inoltre, chi ci dice che in futuro non emerga una tecnologia di accesso ai dati così diversa da quella attuale da rendere la nostra astrazione insufficiente? E se tra 5 anni IBM producesse un computer quantico su cui gira solo Linux e il cliente si trovasse obbligato a riscrivere tutta l'applicazione, rendendo inutile il nostro sforzo (e i soldi spesi dal committente) per astrarre EF?

In definitiva, mi chiedo perchè si dovrebbe far pagare al cliente per qualcosa che non ha richiesto e che nemmeno noi sappiamo se serva davvero. Non abbiamo una sfera di cristallo e non sappiamo stimare nè se sarà necessario cambiare tecnologia di accesso ai dati nè quanto costruire un'astrazione oggi potrebbe far risparmiare al cliente nel lungo termine.

Infine, evitando questo genere di astrazioni che inevitabilmente incrementano i costi della versione 1.0, un vostro concorrente potrebbe proporre una soluzione equivalente alla vostra, a un prezzo inferiore.

My two cents.

Secondo me è uno spreco, perchè si decide di allocare risorse per qualcosa che non è stato richiesto. Anche se non rallenta il lavoro è comunque un costo che viene sostenuto e che il cliente deve pagare. Inoltre, come dicevo, non si ha nessuna certezza che il costo di astrarre EF sia inferiore ad affrontare, in futuro, la migrazione ad un'altra tecnologia (sempre messo che questa migrazione avvenga). Non si sà infatti come sarà questa nuova tecnlogia, nè quali tool per la conversione saranno disponibili, ecc.

Inoltre, immaginate se anni fà si fosse sviluppato un'astrazione di Windows Forms e ora si dovesse sostituire il backend con WPF. Per quanto bravo fosse lo sviluppatore incaricato di questo lavoro, secondo me il risultato sarebbe tutt'altro che ottimale, in quanto le tecnologie sono molto differenti e sei costretto a lavorare sul lowest common denominator.

Concordo che la possibilità di investire in qualcosa come l'astrazione di EF (che ha effetto positivo soltanto sulla qualità interna del codice) è possibile proporle al committente e discuterne.

Ciao Luca, utilizzare il pattern MVC per separare logica e interfaccia utente è una cosa molto diversa da creare un wrapper di Windows Forms (almeno, per come io intendo il termine wrapper).

Scrivere un wrapper di Windows Forms significa scrivere qualcosa come il wxWidget toolkit o il framework utilizzato da Eclipse per l'interfaccia utente (non ricordo il nome). In questo caso tu definisci un frontend (IWindow, IButton) e uno o più backend (WinFormWindow, WPFWindows, etc.).

Io ho inteso che quanto volesse fare Roberto con EF fosse un'operazione di questo tipo.

Mi spiego meglio. Con MVC, hai disaccoppiato la logica dall'interfaccia utente, ma non hai disaccoppiato l'interfaccia utente da Windows Forms. Disaccoppiare l'interfaccia utente da Windows Forms significa appunto scrivere un toolkit come wxWidget.

Tornando all'argomento iniziale, EF, secondo me è bene disaccoppiare il codice di accesso ai dati dalla logica applicativa, ma disaccoppiare il codice di accesso ai dati dal framework di persistenza, wrappandolo, è un'operazione costosa e difficilmente giustificabile.

Ciao Luca, per esemplificare il mio punto di vista mi limito a parlare del recupero dei dati e non della loro persistenza, perchè mi è più facile fare l'esempio.

Come faresti un wrapper Entity Query Language? Scriveresti un tuo linguaggio e poi un traduttore in EQL? Oppure faresti soltanto qualcosa simile alla Criteria API di NHibernate?

Io di solito faccio semplicemente una o più classi QueryHelper, dove definisco metodi quali FindEmployeesBySalary, FindAllCategories, ecc. In questi metodi uso direttamente HQL di NHibernate. Se un domani dovessi davvero cambiare meccanismo di persistenza semplicemente riscriverei i QueryHelper*. Tramite le classi QueryHelper ho disaccoppiato la mia logica applicativa dalla tecnlogia di accesso ai dati, ma non ho certo scritto un wrapper di NHibernate. Personalmente, mi sembra un livello di disaccoppiamento sufficiente, ritengo disaccoppiare i QueryHelper da NH un po' sovraingegnerizzato. Inoltre, secondo me, wrappare EQL comporta una probabilità di introdurre bugs molto più elevata di una soluzione come questa (il testing dei query helper è elementare).

Se analizziamo i costi abbiamo due ipotesi.

Ipotesi 1: EF si evolve in maniera retrocompatibile, il vantaggio di wrappere EQL è nullo e il costo fatto sostenere al cliente non viene recuperato.

Ipotesi 2: EF viene sostituito da una tecnologia diversa:
- se abbiamo scritto un wrapper di EQL
- costo design del wrapper
- costo implementazione per EQL
- costo implementazione per nuova tecnologia
- eventualmente costo di modifica dei wrapper (se la nuova tecnologia è molto diversa)
- se abbiamo semplicemente scritto dei QueryHelper
- costo riscrittura dei QueryHelper

Nella seconda ipotesi può anche essere che, se le query sono davvero molte, wrappare EQL risulti nel lungo termine conveniente per il cliente. Tuttavia questo vantaggio va ponderato in relazione alle probabilità con cui le due ipotesi si verificano.

In economia si parla anche di "valore monetario del tempo", quindi per il cliente potrebbe essere meglio risparmiare 10 oggi che risparmiare 30 tra 5 anni.


* Se volessi fare le cose "per bene" potrei estrarre delle interfacce e fare dependency injection, ma questo ho visto che si può fare in fase di refactoring senza troppe controindicazioni.

Ciao Luca, purtroppo mi ero perso quel tuo post. Molto utile, soprattutto perchè fornisce una terminolgia comune.

La scrittura di un wrapper coincide quindi con l'approccio "Skin and Wrap the API", che penso fosse quello preso in considerazione da Roberto.

"Responsability-Based extraction", che è l'approccio da me usato scrivendo i QueryHelper, mi sembra una pratica abbastanza comune e strettamente legata a "separation of concerns", utile non solo per isolare la dipendenza da EF, ma anche per la scrittura di test e la manutenzione.

Anche avendo un wrapper di NH o di EF a disposizione, a mio parere, sarebbe comunque bene fare "Responsibility-based extraction". Rimanendo nel nostro esempio, effettuare le query dall'interfaccia utente, siano esse fatte con il nostro wrapper o direttamente con EF, è comunque una pratica da evitare, soprattutto perchè non consente di scrivere unit test per queries. Inoltre, isolare le query - manualmente o usando dei tool di refactoring - è un'operazione a costo praticamente nullo.

PS

Riprendendo l'altro esempio, usare MVC (o rifattorizzare a MVC) può essere visto come una "Responsibility-Based extraction", mentre scrivere un wrapper come wxWidget è un approccio "Skin and Wrap the API".

Probabilmente, come dici tu stesso nell'altro post, in presenza di API molto complesse è sufficiente fare "Responsibility based extraction".

Se invece si tratta di isolare un'API semplice, per esempio un singolo controllo GDI+ di terze parti, sono convinto anch'io che "Skin and wrap the API" è un approccio valido e da tenere sicuramente in considerazione.