Entity Framework ObjectContext in windows/WPF/Silverlight application

We are writing a WPF application using Entity framework (Silverlight with RIA services to be precise). We're using a shared ObjectContext through the application so that we can benefit from sharing data across the modules.

The problem is - if user during his work opens let's say historical sales, it gets loaded to the ObjectContext and stays there until the end of the application. So another pattern should be used.

I know that ObjectContexts should be used as single Unit-of-Work. But then, ho开发者_高级运维w do you let other parts of the application know that something has changed and they should reload their data?

Edit: Ok, EventAggregator, but then, this would cause all other parts to reload their (probably much of it duplicate) data. Also probably many event would be needed for all the types of entites groups.

How do you solve these problems? My current solution is a kind of compromise - use a shared ObjectContext for the core data used by whole appliaction so that they can be shared and updated automatically. And for the large amount of data, use a new separate ObjectContext. Any better ideas?

Is there a way how to "release" entities from their DataContext so that Garbage collector can do its job and release the memory?

Wait, is it WPF or Silverlight? In this case, they are very different and my answer would be different.

WPF Solution

In WPF I would create a single ObjectContext per form. This way, the context will only last as long as the form itself. You should then implement an event system so that when you save changes to an entity you can alert the other forms that they may need to refresh their data (INotifyPropertyChanged, for example). Oren Eini wrote a pretty good article on this architecture using NHibernate in MSDN magazine. You should be able to get the architecture concept from his article.

Silverlight Solution

Now, Silverlight is different. Silverlight essentially only allows you to have one form in your application. Yes, there are some tricks you can do to navigate the root visual of the form to different "pages" but it is still only one form and the user can't open multiple windows in one Silverlight RIA. Because of this, I would make one .Net RIA Services ObjectContext per Silverlight RIA instance. Remember, RIA Services is not an actual connection to your database, it is just a caching and change tracking object linked to a web service. So, it is perfectly acceptable to leave this object in existance for longer periods of time because it is not tying up any server resources. If your Silverlight RIA opens multiple browser windows or has more than one Silverlight object, then you should have one ObjectContext per Silverlight instance.

On the server, you use an Entity Framework ObjectContext in the web service and it should only live for the duration of one request. The more stateless you can make your services, the more scalable and performant they will be. You want to open your EF ObjectContext, use it, and close it as soon as possible.

EDIT:

If all you are wanting to do is detach an object from the object context, then you can just use the context.Detach(entity) method. You can find an example of how to do this on MSDN.

You could use repository pattern. An additional layer of abstraction between UI and DAL.

Make Data collections in repository static and observable. Then whenever repository updates any of them, UI layer should catch up. JUst an idea.

Use ObservableCollections in the ObjectContext. Use an event that triggers on NotifyPropertyChange. Use a publish/subscribe pattern between the view models to inform them of the change and use this to update the other views.

In our case we have decide to implement a factory pattern and instantiate a new object context whenever we need it (sometimes it does not map one to one to a VM).

Agreat article about object context life time: http://www.silverlightshow.net/items/Silverlight-WCF-RIA-Services-strategies-for-handling-your-Domain-Context-part-one.aspx