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

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

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

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 :-)