Come ho accenato durante la sessione ai CD 2008, sto lavorando con EF su database Oracle. Voglio segnalare alcuni contenuti tecnici per chi volesse cominciare a lavorare in questo senso.
Al momento sto lavorando con Oracle 10g Express su macchina virtuale Windows 2003 Server R2 (VmWare), come data provider per EF ho valutato la trial di OraDirect.NET della DevArt e devo dire che funziona molto bene nel senso che non ho notato quasi nessuna differenza da utilizzatore rispetto a quello per SQL Server standard. Ovviamente è un prodotto che non si limita a fornire un data provider per EF, è un AFO.NET data provider per Oracle a tutto tondo. L'installazione prevede l'aggiunta di un menu piuttosto corposo fra i tool (più una serie di docking windows) di Visual Studio .NET 2008, il costo della licenza a mio avviso è assolutamente corrispettivo della qualità (la licenza singola Professional costa 200 $).
Nella mia esperienza professionale ho lavorato poco con Oracle, devo dire che mi aspettavo peggio per quanto riguarda i tool di amministrazione abituato al Management Studio di SQL Server, in fondo L'Oracle SQL Developer è utilizzabile anche se un po' lento (è un'applicazione Java che fra le altre cose disabilita temporaneamente Aero perchè non lo supporta).
Da ignorantone di Oracle quale sono ho trovato utile il tool di migrazione da SQL Server incluso nell'Oracle SQL Developer che mi permette di lavorare con SQL Server con cui mi trovo più a mio agio durante la progettazione del DB. Ho fatto diverse prove e mi sembra che il risultato della procedura di migrazione sia abbastanza accurato e usabile.
In questo senso questa guida è ben fatta e abbastanza chiara anche se la procedura più corretta per l'installazione dei driver per SQL Server è in questo post del forum Oracle. Nota a margine: nella finestra di nuova connessione, quando si cerca di connettersi ad SQL Server il nome dell'host da inserire è solo quello della macchina su cui è installato SQL Server anche se ci fossero una o più istanze nominate. Ci ho perso un'ora a capirlo e con sorpresa, una volta scoperto, nella lista dei database disponibili ho trovato tutti i db di tutte le istanze (io ho una SQL 2005 Express e una SQL 2005 Developer). In realtà di ore ne ho perse due... ho scoperto che le connessioni TCP/IP a SQL Server, anche se abilitate da console di amministrazione, potrebbero cmq non funzionare se nelle proprietà, alla voce "IPAll" del tap "IP Addresses", il setting "TCP Port" è vuoto. La cosa strana è che la porta 1433 è correttamente indicata nel tab "Protocol", ma a quanto sembra se non viene comunque associata anche agli indirizzi IP (la voce "IPAll" è quella che li referenzia tutti), non funziona. Questo post che ho trovato in rete chiarisce gli step per ovviare alla questione (la porta da specificare è sempre la 1433 o comunque quella scelta nel tab "Protocol").
La cosa che mi ha fatto più piacere è stata creare un Entity Data Model a partire da un db SQL Server, migrare il db su Oracle, creare un nuovo EDM per il db Oracle replica esatta di quello per SQL Server, cambiare nelle query il riferimento all'ObjectContext e vedere che tutto funzionava nello stesso identico modo.
Unica nota negativa: se si utilizza il designer per creare un EDM non c'è verso di mettere mano al codice prodotto in automatico, nel senso che alla compilazione seguente Visual Studio lo riazzera ed in pratica lo riscrive (bella scoperta.. lo fanno tutti i designer di Visual Studio). Mi era venuto in mente di mettere a fattore comune le entità di dominio fra i due EDM, in modo che l'unica differenza fossero i file di mapping e gli ObjectContext, ma non è fattibile in pratica utilizzando il designer. Si potrebbe fare a mano, ma sinceramente di mettermi a manina a definire tutti gli attributi necessari alle classi delle entità e scrivere i file xml di mapping è una rottura di scatole che al momento non ho proprio voglia di affrontare...