Home/ Questions/Q 540441
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T10:14:26+00:00

We are writing a WPF application using Entity framework (Silverlight with RIA services to

  • 0

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, how 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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0