16 messaggi dal 21 maggio 2007
Ciao

Sto seguendo insieme ad un collega la progettazione di un nuovo sistema. Avendo a disposizione abbastanza tempo rispetto alla quantità dei requisiti volevamo cominciare ad esplorare le nuove tecnologie offerte dal mondo microsoft.

Il primo passo volevamo muoverlo verso l'adozione di entity framework.

Appena provato però a muovere i primi passi siamo subito incappati in dubbi atroci.

Andiamo un attimino indietro: sono abituato a modellare il mio dominio da zero, o dal db, creando comunque delle entity POCO. Come ORM uso NHibernate da ormai due anni. Per implementare il DAL mi sono sempre basato, come punto di partenza su una interfaccia che astraesse il particolare datacontext o session che si andava ad utilizzare, sulla falsa riga di quella che era la IUnitOfWork di NSK, per intenderci.

Ovviamente io volevo mantenere lo stesso approccio anche con entity framework.
Tralasciando le entity non POCO, il problema più grosso che ho riscotranto è quello che gli ObjectContext non mi mettono a disposizione metodi per il caricamento delle entity del tipo Load<T>(). Ho trovato solo soluzioni simili, come la CreateQuery, che però richiedono come parametro il nome dell'entityset che si desidera ed ovviamente io non la voglio indicare.

Sono solo ai primi passi e quindi non conosco a fondo EF, quindi potrei avere la soluzione sotto il naso e non vederla.

Avete quindi qualche consiglio da darmi? Ovvero: esiste un modo per caricare le istanze desiderato come permette la session di NHibernate? esiste altrimenti un modo intelligente per simulare quel comportamento?

Grazie mille per le risposte che vorrete dare ai dubbi di due poveri disgraziati alle prime armi.
Ciao,

purtroppo niente da fare, EF è ancora un po' "acerbo" sotto questo punto di vista e non espone un generico GetById<T>(id)

Ne parlottavo su MSN poco fa con il caro Roberto Messora, e AFAWK non c'è una soluzione immediata al problema, se non gironzolare via reflection per il tuo ObjectContext fino a recuperare l'ObjectQuery<T>, il cui nome è proprio l'EntitySetName di cui hai bisogno.

m.
16 messaggi dal 21 maggio 2007
Ciao

Innanzitutto grazie per la repentina risposta.

Mi viene quindi da chiedere ulteriormente: supponiamo che io decida di andare avanti per la mia strada ed utilizzare EF sebbene sia un po acerbo; secondo te (voi) mi conviene aggirare il problema con la reflection, magari temporaneamente in attesa di una versione più matura (se mai arriverà) mantenendo quindi un buon livello di astrazione per il dal, oppure è meglio legare l'intera applicazione ad EF utilizzandolo direttamente all'interno del mio business?
Oppure magari c'è una terza strada che non vedo (cosa probabile)  ?

Grazie

Matteo
Mah... la mia idea in proposito è che se si usa un framework di persistenza, difficilmente ci si troverà a cambiarlo con un altro ad applicazione in corso, e se pure lo si facesse, le peculiarità di ognuno sono talmente diverse che non vale la pena wrappare il mondo per non introdurre dipendenze: troppo costoso, complesso e soprattutto non ci dà modo di sfruttare EF (o NH o iBatis o Genome o qualunque altro ORM) al meglio delle potenzialità.

In ogni modo, se ti può consolare, usando EF hai già un sacco di dipendenze nel domain model che vengono sparpagliate per tutti i layer applicativi
16 messaggi dal 21 maggio 2007
Anche se un po in ritardo, grazie per i consigli.

Per quanto riguarda le dipendenze: no non mi consoli, anzi

Ne approfitto per farti i complimenti per il tuo WebCast su EF.
E visto che non fa mai male (e che oggi mi sento un po lecchino  ) ti ringrazio anche per i tuoi svariati post sul tuo (tuoi) blog che mi hanno aiutato molto con NHibernate. Continua così che noi poveri mortali abbiamo bisogno di gente come te.

Ciao
12 messaggi dal 19 gennaio 2006
Mi viene quindi da chiedere ulteriormente: supponiamo che io decida di andare avanti per la mia strada ed utilizzare EF sebbene sia un po acerbo; secondo te (voi) mi conviene aggirare il problema con la reflection, magari
temporaneamente in attesa di una versione più matura (se mai arriverà) mantenendo quindi un buon livello di astrazione per il dal, oppure è meglio
legare l'intera applicazione ad EF utilizzandolo direttamente all'interno del mio business?
Attenzione: NSK è un esempio "estremo". E' estremo perchè usa un modello a plug-in per il DAL che risponde al requisito "poter cambiare tutto quello che c'è sotto". Se ciò che ti interessa è "soltanto" supportare DBMS differenti, in esplicita presenza di un O/RM con supporto di DBMS "multi-vendor" quello di NSK non è un approccio consigliabile. Ergo, non farti problemi ed usa direttamente ObjectContext nei tuoi servizi :-)

.A
GUISA - http://www.guisa.org
UGIdotNET - http://www.ugidotnet.org
Read my blog at: http://blogs.ugidotnet.org/pape
16 messaggi dal 21 maggio 2007
In effetti usare direttamente l'ObjectContext specifico, come mi suggeriva anche Crad, ti permette di sfruttare appieno le funzionalità da esso offerte. Più che l'astrazione in sè, però, le cose che mi mancano di più del non avere un interfaccia simil NSK sono sostanzialmente due:
-la possibilità di avere un metodo generico per l'accesso al dominio (tipo Get<T>)
-la facilità con cui puoi Testare il business layer

Ovviamente spero di essere smentito!

P.S. l'approccio da noi adottato alla fine è proprio quello di usare direttamente l'ObjectContext e, a parte i problemi dovuti all'inesperienza con EF, siamo comunque molto soddisfatti.

Ciao e grazie!

Matteo

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.