Ciao,
code-first è semplicemente un altro approccio allo sviluppo di un'applicazione. Ti permette di aggredire il problema da un angolo diverso, non è necessariamente migliore o peggiore del database-first (o model-first che dir si voglia).
A me per esempio piace prima ragionare sulle tabelle di un db e solo poi scrivere il codice. Probabilmente continuerò a preferire l'uso di Entity Framework nella maniera "classica". Riconosco tuttavia il "fascino" di code-first perché, per esempio, mi permette di eliminare la dipendenza della mia applicazione da Entity Framework, ed è anche più testabile. Inoltre, se un giorno volessi sostituire EF con NHibernate sarebbe di certo più semplice.
E' pur vero che le maggior parte (se non tutte? :) delle applicazioni che scrivo io sono abbastanza modeste ed è improbabile che mi capiti in futuro la necessità impellente di cambiare ORM. Quindi non mi suscita nessuna preoccupazione il continuare col sistema database-first.
Il punto è che code-first non è una novità. Il suo supporto è stato introdotto solo ora da Microsoft in seguito alle insistenti (e legittime) richieste di coloro che reputavano EF un
prodotto incompleto.
Cambiare un bel po' di classi nei vecchi progetti porta con sè qualche vantaggio reale, chessò prestazioni migliori o miglior supporto in futuro, oppure diciamo che il gioco non vale la candela?
No. Tieni presente questo: se ottenere il massimo delle prestazioni ha un'importanza imprescindibile per te, perché hai sviluppato le tue applicazioni con Entity Framework e non con NHibnernate, che è un prodotto più matur, che usa approccio code-first da anni e che ha tonnellate di opzioni per ottimizzare la singola query? Oppure perché non scartare del tutto l'ORM e usare direttamente i DataReader?
Io ho scelto Entity Framework model-first perché ho un bel designer integrato in Visual Studio che mi genera le classi a partire dal database che ho disegnato io, attorno a determinate esigenze. Alla fine della giornata posso ritenere di essere stato produttivo e preciso. Non mi sento affatto in colpa se le prestazioni sono il 95% di quelle che avrei potuto ottenere con un sistema che mi avrebbe reso però meno produttivo.
Ovviamente per progetti molto importanti, in cui le prestazioni, la modularità e manutenibilità sono essenziali la scelta va ponderata meglio. Magari sacrifico la comodità del designer e prediligo invece la scelta che mi da prestazioni migliori. Dipende dalla situazione.
è da prendere in considerazione solo per nuove applicazioni
Sì, ma a volte non hai neanche possibilità di scelta. Se devi sviluppare un'applicazione attorno ad un database che già esiste, secondo me è una perdita di tempo usare code-first. Poi, per carita, in un mondo perfetto lo sviluppatore avrebbe la libertà di consegnare il prodotto "quando è pronto" e, non avendo sul groppone il macigno delle deadline, avrebbe la libertà di seguire la strada che ritiene migliore.
Ad ogni modo, non mi fraintendere, io non penso affatto che code-first sia incredibilmente complicato. Qui su aspitalia trovi diversi articoli che ti spiegano come effettuare il mapping da interfaccia fluente. E' una pacchia, ma io adoro di più sbragarmi sul designer grafico.
Il mio post prendilo per quello che è: un'opinione. Spero che un po' ti sia utile, ho visto che non avevi ricevuto risposte...
ciao
Modificato da BrightSoul il 12 luglio 2011 21.24 -
