Ho letto questo tutorial e questo articolo ma non capisco esattamente l'uso di ogni tipo di caricamento.
Io spiego
Ho questo POCO:
public partial class dpc_gestion
{
public dpc_gestion()
{
this.ass_reunion_participant = new HashSet<ass_reunion_participant>();
this.dpc_participant = new HashSet<dpc_participant>();
this.dpc_reunion = new HashSet<dpc_reunion>();
}
public int dpc_id_pk { get; set; }
public Nullable<int> dpc_id_gdp_fk { get; set; }
public Nullable<int> dpc_id_theme { get; set; }
public int dpc_id_animateur_fk { get; set; }
public Nullable<System.DateTime> dpc_date_creation { get; set; }
public Nullable<System.DateTime> dpc_date_fin { get; set; }
public Nullable<System.DateTime> dpc_date_engag_anim { get; set; }
public Nullable<bool> dpc_flg_let_engag_anim { get; set; }
public Nullable<bool> dpc_flg_fsoins_anim { get; set; }
public virtual ICollection<ass_reunion_participant> ass_reunion_participant { get; set; }
public virtual theme_dpc theme_dpc { get; set; }
public virtual gdp_groupe_de_pair gdp_groupe_de_pair { get; set; }
public virtual ICollection<dpc_participant> dpc_participant { get; set; }
public virtual ICollection<dpc_reunion> dpc_reunion { get; set; }
}
Ho capito questo:
Per il caricamento Lazy : poiché il carico è pigro, se chiamo dbset dpc_gestion
tutte le proprietà di navigazione non verranno caricate. Questo tipo di caricamento è il migliore in termini di prestazioni e reattività. È abilitato per impostazione predefinita e, se desidero riattivarlo, devo impostare:
context.Configuration.ProxyCreationEnabled = true;
context.Configuration.LazyLoadingEnabled = true;
Per il caricamento avido non è pigro: ha caricato tutte le proprietà di navigazione quando carico dpc_gestion
. Le proprietà di navigazione possono essere caricate utilizzando il metodo include
. Per abilitare questo tipo di caricamento:
context.Configuration.LazyLoadingEnabled = false;
Per il caricamento esplicito è come il caricamento avido ma usiamo il metodo di Load
invece di include
.
Quindi mi piacerebbe sapere:
dpc_gestion.dpc_participant
, ad esempio, vengono dpc_gestion.dpc_participant
le proprietà di navigazione o dpc_gestion.dpc_participant
un'eccezione? Grazie
Se questo piccolo curriculum è vero?
Sì.
Se è vero, qual è la differenza tra caricamento desideroso ed esplicito?
Il caricamento Eager è l'opposto del caricamento Lazy, ma il caricamento esplicito è simile al caricamento lazy , eccetto che: si richiamano esplicitamente i dati relativi nel codice; non accade automaticamente quando accedi a una proprietà di navigazione. Caricare manualmente i dati correlati recuperando la voce di gestione stato oggetto per un'entità e chiamando il metodo Collection.Load
per le raccolte o il metodo Reference.Load
per le proprietà che contengono una singola entità.
Dal techblog :
Carico:
Il caricamento Eager è l' opposto del caricamento Lazy che è: il processo di caricamento di un insieme specifico di oggetti correlati insieme agli oggetti che sono stati esplicitamente richiesti nella query.
Caricamento esplicito:
Il caricamento esplicito è definito come: quando gli oggetti vengono restituiti da una query, gli oggetti correlati non vengono caricati contemporaneamente. Per impostazione predefinita, non vengono caricati fino a quando non vengono richiesti esplicitamente utilizzando il metodo Load su una proprietà di navigazione.
E:
Se utilizzo il caricamento lazy e chiamo
dpc_gestion.dpc_participant
, ad esempio, vengonodpc_gestion.dpc_participant
le proprietà di navigazione odpc_gestion.dpc_participant
un'eccezione?
Non ottieni alcuna eccezione e le proprietà di navigazione dovrebbero essere caricate.
C'è un caso in cui il caricamento ansioso o il carico esplicito erano migliori di un caricamento lento in termini di prestazioni e reattività?
Il caricamento di tipo Eager è in genere più efficiente quando sono necessari i dati correlati per tutte le righe recuperate della tabella primaria. E anche quando le relazioni non sono eccessive, il caricamento impaziente sarà una buona pratica per ridurre ulteriormente le query sul server. Ma quando sai che non avrai bisogno di una proprietà istantanea, allora il caricamento lento potrebbe essere una buona scelta. E anche il carico impaziente è una buona scelta in una situazione in cui il tuo contesto db viene eliminato e il caricamento lento non può più avvenire. Ad esempio, considera quanto segue:
public List<Auction> GetAuctions()
{
using (DataContext db = new DataContext())
{
return db.Auctions.ToList();
}
}
Dopo aver chiamato questo metodo, non è possibile caricare l 'entità correlata pigramente perché il db
è disposto e quindi il caricamento Eager sarebbe una scelta migliore qui.
Un'altra cosa da notare è: il caricamento lento produrrà diverse richieste SQL mentre Eager carica i dati di carico con una richiesta. Il caricamento di Eager è anche una buona scelta per risolvere il problema dei n + 1 in ORM. Dai un'occhiata a questo post: Qual è il problema di selezione di n + 1?
Domanda 1 e 2:
La tua spiegazione del carico pigro e del carico impaziente è corretta.
L'uso del caricamento esplicito è leggermente diverso da quello che hai descritto.
EntityFramework
restituisce oggetti IQueryable
, che contengono essenzialmente la query sul database. Ma questi non vengono eseguiti fino alla prima volta in cui vengono enumerati.
Load
esegue la query in modo che i suoi risultati siano memorizzati localmente.
Chiamando Load
è lo stesso di chiamare ToList
e buttare via quella List
, senza avere il sovraccarico di creare la List
.
Domanda 3:
Se si utilizza il caricamento lazy, EntityFramework
si prenderà cura di caricare la proprietà di navigazione per te, in modo da non ottenere un'eccezione.
Tieni presente che ciò può richiedere un po 'di tempo e rendere l'applicazione non rispondente .
Domanda 4:
In casi disconnessi (ad es. Applicazione di rete) non è possibile utilizzare il caricamento lazy , poiché questi oggetti sono tradotti in DTO e quindi non tracciati da EntityFramework
.
Inoltre, se sai che utilizzerai una proprietà di navigazione , è buona norma caricarla con entusiasmo , in modo da non dover attendere che vengano caricati dal database.
Ad esempio, supponiamo di memorizzare il risultato in un elenco e associarlo a un DataGrid WPF. Se DataGrid accede a una proprietà che non è ancora stata caricata, l'utente subisce un timeout notevole finché non viene visualizzata la proprietà. Inoltre l'applicazione non risponderà durante il tempo di caricamento (se non si carica in modo asincrono).