Ormai utilizzo Entity Framework da quasi un anno, e presso un cliente lo sto facendo adottare perchè questo vuole utilizzare solo tecnlogia proprietaria Microsoft. LINQ To SQL non è abbastanza potente quindi la scelta è ovvia.
Quando mi ritrovo a spiegare Entity Framework l'argomento più complicato non è l'Object Tracking o il supporto per scenari su più layer, logici o fisici che siano, o l'EntitySql; l'argomento più complesso è il Mapping. Senza dubbio il mapping in un ORM è il concetto più semplice da capire, ma con Entity Framework nonostante il facile compito si è riusciti a colpire la classica mosca col bazzuca, ma tant'è e così ce lo teniamo.
All'inizio, ho utilizzato il designer in ctp ma la mia voglia di imparare era tale che dopo pochi giorni sono passato direttamente a fare le cose a manina. Passare da dei tool che ti creano tuto da video a scrivere un xml a mano è pura follia, ma ormai non riesco a farne a meno, il designer proprio non lo so usare :)
Alla lunga però paga perchè scrivere il mapping a mano e verificare gli errori fa capire quali sono le necessità di Entity Framework e fa più o meno intuire come lavora il motore.
Ai Community Days, stavo impazzendo con Roberto perchè lui non riusciva a riprodurre l'ereditarietà Table Per Type e io invece.... nemmeno :). Lui utilizzava il tool e io non sapevo nemmeno cosa stesse facendo quindi mi sono buttato sul file XML. Dopo un vago girare a vuoto, mi sono accorto che nel file SSDL (quello della descrizione dello storage e occhio ho detto storage e non database) non c'era la descrizione dell'associazione tra la tabella primaria e quella secondaria con i campi aggiuntivi. Dimenticando di descrivere quest'associazione, Entity Framework non sapeva come mettere in join le tabelle e generava un'eccezione. Qui si scatena un putiferio; le eccezioni di mapping sono la cosa più oscura del mondo; per la semplice mancanza dell'associazione siamo finiti per avere un messaggio di perdita di dati dovuta alla non conoscenza del lato C della tabella padre. Pensandoci bene, uno particolarmente malato forse potrebbe anche arrivare a capire l'errore ma non sono molto fiducioso.
Insomma, tutto questo per dire una cosa: fatevi i file XML a mano. Probabilmente la prima settimana riuscirete a mappare solo 4 tabelle sulle classi analoghe sputando anche svariato sangue, ma state tranquilli che lo sforzo verrà ampiamente ripagato dopo poco tempo. Personalmente adoro questa piccola applicazione che è una miniera di informazioni per il mapping.
Stay Tuned...
Ciao Rob,
alla fine lavorandoci insieme possiamo mappare di tutto :D.
Cmq è vero, gli attributi sono odiosi. Mi sembra che siano cmq diminuiti, prima c'erano anche per le FK tra classi, adesso non mi pare siano più usati.
Ma l'attributo più bello secondo me è quello con cui si decora l'assembly che contiene le classi, una vera chicca.
Byez
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download 
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
Alla fine però ce l'abbiamo fatta entrambi grazie proprio a quella piccola, ma utilissima applicazione.
Il mio punto di vista sul designer è un po' più "lasco", ovvero lo utilizzo per il primo scketch (caricare una tabella/entità) e poi rifinire a mano (tanto più che molte delle associazioni sono già cmq corrette nel designer). in fin dei conti già da nhibernate siamo in confidenza con i file di mapping in formato xml. il vero e tedioso lavoro, almeno dal mio punto di vista è la scelta e l'applicazione della pletora di attributi da utilizzare con le classi entità...
Ciao
Roberto
Continua »»» | Rispondi »»»