365 messaggi dal 08 febbraio 2009
Salve a tutti.

Non riesco a capire una cosa nella gestione dei livelli.
Sto provando a "studiare" il Model Virtual Casting presentato dai gestori del forum (spero di non aver detto delle cavolate).

Finchè parliamo di IQueryable mi sembra di aver capito come funziona (devo proseguire con un po' di test, però i primi hanno dato esito positivo).

Quando invece mi sono messo ad analizzare il metodo "Include", non ho capito bene come funziona.

O meglio, la "Include" si appoggia al motore di RF.
Per funzionare, però, mi pare di aver capito che tutte le volte il Repository viene creato "ex novo" e la "Include" viene accodata al DbSet attuale...

E' così?
E se un DAL non avesse l'utilizzo di EF? Come si dovrebbe fare per gestire le "Include"?
JoeRuspante wrote:
Per funzionare, però, mi pare di aver capito che tutte le volte il Repository viene creato "ex novo" e la "Include" viene accodata al DbSet attuale...

no, il metodo Include non fa questo. in realtà, il metodo Include dice al motore di EF come materializzare i dati. in parole povere, se tu devi tirare fuori una entità collegata, la prepara in maniera tale che non debba essere caricata se necessario. questa cosa, in scenari disconnessi (ad esempio, facendo uso di cache) è l'unica cosa possibile, perché l'istanza dell'object context non esiste più

E se un DAL non avesse l'utilizzo di EF? Come si dovrebbe fare per gestire le "Include"?

non avrebbe senso. Include è qualcosa che va utilizzato quando integri LINQ dentro la tua architettura. in una classica architettura basata su un DAL classico, dove non usi LINQ, è già così: la tua query materializza quello che serve e lo fa subito. con LINQ, invece, le query non le scrivi e devi aiutare il motore a farti materializzare già quello che ti serve. "tutto qui"

Daniele Bochicchio | ASPItalia.com
I libri su HTML5, WP7, ASP.NET, VB, C#, Entity Framework
Senior Software Architect@5DLabs.it
Microsoft Regional Director for Italy
365 messaggi dal 08 febbraio 2009
Grazie per la risposta.

Però non mi è chiara la cosa.
Di suo qual è il principio di "Include" lo so, l'ho letto in diversi manuali su EF.

Però mi sembrava che per "metterlo in pratica" si debba comunque fare riferimento ad EF...

Questo però non si sposa con la teoria dei 3 livelli: ogni livello dovrebbe essere indipendente e lavorare con gli altri come se fossero delle scatole nere.
Invece, usando "Include", vuol dire che il BIZ e la UI danno per scontato che sotto ci sia EF.

E' così?

Lo chiedo perchè pensavo di aver capito male, bensì che la "Include" si potesse usare anche per altri motori di persistenza.


Tanto che ci sono, posso chiedere una cosa aggiuntiva? Nelle vostre esperienze (e mi pare ne abbiate tante), conviene usare LINQ ed EF per un gestionale? Spesso leggo che LINQ ha problemi di lentezza, così come non sempre è chiaro il modo in cui vengano "mappate" le query... Per cui per sfruttare le potenzialità del DB sembra non essere lo strumento adatto.

Dall'altra parte, però, mi sembra strano che Microsoft punti tanto a questo modo di programmare se poi non è vantaggioso...

Sapete dove posso trovare dei paragoni sensati di pro/contro fra EF e uno sviluppo tradizionale?

PS: Per "tradizionale" intendo dei metodi che hanno come parametri i filtri, gli ordinamenti, i dati di paginazione... e poi mappano la query a manina, tornando un IEnumerable
JoeRuspante wrote:
Invece, usando "Include", vuol dire che il BIZ e la UI danno per scontato che sotto ci sia EF.
E' così?

certo che è così. quando integri LINQ nella tua archiettura (ma, in realtà, vale un po' per un qualsiasi ORM a scelta), devi stare a certe regole. Cristian ha scritto un bel post qui:
http://blogs.aspitalia.com/ricciolo/post2690/LINQ-Lazy-Loading-Architettura.aspx
PS: Per "tradizionale" intendo dei metodi che hanno come parametri i filtri, gli ordinamenti, i dati di paginazione... e poi mappano la query a manina, tornando un IEnumerable

tu hai bisogno di persistere un grafo di oggetti? se la risposta è sì, Entity Framework/un ORM vince a mani basse. dipende da quello che devi fare, perché, sostanzialmente, un ORM conviene quasi sempre. se devi generare query dinamiche e/o fare pesanti calcoli sui dati no, ma in quel caso la soluzione è sempre scriversi le query ad hoc.
.

Daniele Bochicchio | ASPItalia.com
I libri su HTML5, WP7, ASP.NET, VB, C#, Entity Framework
Senior Software Architect@5DLabs.it
Microsoft Regional Director for Italy

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.
Community
Ultimi messaggi
UTENTI ONLINE
In primo piano

I più letti di oggi

Media
In evidenza
MISC