Entity Framework ObjectContext nell'applicazione windows/WPF/Silverlight

Question

Stiamo scrivendo un'applicazione WPF utilizzando il framework Entity (Silverlight con i servizi RIA per la precisione). Usiamo un ObjectContext condiviso attraverso l'applicazione in modo che possiamo beneficiare della condivisione dei dati tra i moduli.

Il problema è che se l'utente durante il suo lavoro si apre diciamo vendite storiche, viene caricato nell'ObjectContext e rimane lì fino alla fine dell'applicazione. Quindi dovrebbe essere usato un altro modello.

So che ObjectContexts deve essere utilizzato come singola unità di lavoro. Ma poi, come fai a sapere che altre parti dell'applicazione sanno che qualcosa è cambiato e che dovrebbero ricaricare i loro dati?

Modifica: Ok, EventAggregator, ma in questo modo tutte le altre parti ricaricheranno i dati (probabilmente molti di essi duplicati). Probabilmente anche molti eventi sarebbero necessari per tutti i tipi di gruppi di entit.

Come risolvete questi problemi? La mia soluzione attuale è una sorta di compromesso: utilizzare un ObjectContext condiviso per i dati principali utilizzati dall'intera applicazione in modo che possano essere condivisi e aggiornati automaticamente. E per la grande quantità di dati, usa un nuovo ObjectContext separato. Qualche idea migliore?

Esiste un modo per "rilasciare" entità dal proprio DataContext in modo che Garbage Collector possa svolgere il proprio lavoro e rilasciare la memoria?

Answer 1

Aspetta, è WPF o Silverlight? In questo caso, sono molto diversi e la mia risposta sarebbe diversa.

WPF Soluzione

In WPF vorrei creare un unico ObjectContext per modulo. In questo modo, il contesto durerà fino a quando la forma stessa. Dovresti quindi implementare un sistema di eventi in modo che quando salvi le modifiche a un'entità, puoi avvisare gli altri moduli di cui potrebbero aver bisogno per aggiornare i loro dati (ad esempio, INotifyPropertyChanged). Oren Eini wrote a pretty good article on this architecture using NHibernate in MSDN magazine. Dovresti essere in grado di ottenere il concetto di architettura dal suo articolo.

Silverlight Soluzione

Ora, Silverlight è diverso. In sostanza Silverlight ti consente solo di avere un modulo nella tua applicazione. Sì, ci sono alcuni trucchi che puoi fare per navigare nella visualizzazione radice del modulo in "pagine" diverse, ma è pur sempre un modulo e l'utente non può aprire più finestre in una RIA Silverlight. Per questo motivo, creerò uno .Net Object Rage Services RIA per istanza RIA Silverlight. Ricorda, i Servizi RIA non sono una vera e propria connessione al tuo database, ma solo un oggetto di memorizzazione nella cache e di modifica delle modifiche collegato a un servizio web. Quindi, è perfettamente accettabile lasciare questo oggetto in esistenza per periodi di tempo più lunghi perché non sta legando alcuna risorsa del server. Se Silverlight RIA apre più finestre del browser o ha più di un oggetto Silverlight, è necessario disporre di un ObjectContext per istanza Silverlight.

Sul server, si utilizza un ObjectContext di Entity Framework nel servizio Web e dovrebbe durare solo per la durata di una richiesta. Più gli apolidi possono rendere i tuoi servizi, più scalabili e performanti saranno. Volete aprire il vostro ObjectContext EF, usarlo e chiuderlo il prima possibile.

---

EDIT:

Se tutti si vogliono fare è staccare un oggetto dal contesto oggetto, allora si può solo utilizzare il metodo context.Detach(entity). È possibile trovare un example of how to do this on MSDN.

Answer 2

È possibile utilizzare il modello di repository. Un ulteriore livello di astrazione tra UI e DAL.

Rendi statiche e osservabili le raccolte di dati nel repository. Quindi, ogni volta che il repository ne aggiorna uno, il livello dell'interfaccia utente dovrebbe aggiornarsi. È un'idea.

Answer 3

Utilizzare ObservableCollections in ObjectContext. Utilizzare un evento che si attiva su NotifyPropertyChange. Utilizzare un modello di pubblicazione/sottoscrizione tra i modelli di visualizzazione per informarli della modifica e utilizzarli per aggiornare le altre visualizzazioni.

Answer 4

Nel nostro caso, abbiamo deciso di implementare un modello di fabbrica e di creare un'istanza di un nuovo contesto oggetto ogni volta che ne abbiamo bisogno (a volte non mappa uno a uno su una VM).

Agreat articolo su oggetto tempo di vita contesto: http://www.silverlightshow.net/items/Silverlight-WCF-RIA-Services-strategies-for-handling-your-Domain-Context-part-one.aspx