Question

I use the EF 3.5 in VS 2010. I have a method which returns a struct. In the struct there is an object armatuur. When the struct is returned i want to access the related objects from the armatuur instance.

However

the method returning the struct:

public LampPostDetail getLamppostInfo(int id)
{
    LampPostDetail lpd;

    lpd.xPos = 0;
    lpd.ypos = 0;
    lpd.armatuur = new Armatuur();

    //get the info from object
    using (var db = new OvisionDBEntities())
    {
        var objects = from o in db.Objects
                      where o.ObjectId == id
                      select o;

        foreach (OVSL.Data.Object o in objects)
        {
            lpd.xPos = o.XCoordinatie;
            lpd.ypos = o.YCoordinatie;
            lpd.armatuur = o.Armatuur; //which is a table in my db
        }

        return lpd;
    }
}

struct:

public struct LampPostDetail
{
    #region [ Data Members (14)]
    //lamppost info
    public double? xPos;
    public double? ypos;

    //a lamppost can have several armaturen
    public OVSL.Data.Armatuur armatuur; //is a table in my db

    #endregion [ Data Members ]
}

when doing this in my client:

 LampPostDetail lpd = client.getLamppostInfo(id);
 string brand = lpd.armatuur.producer.name; //producer is related object of armatuur

I get a ObjectDisposedException. I understand that this happens because the LampPostDetail object is disposed after the using block is finished. But how do i get this to work? Retrieving all information I need (like brand name e.g.) before I return it to the client is not not an option.

Answer 1

The only thing that gets disposed here is the OvisionDBEntities context. After that, no lazy loading is possible. How to deal with that? In fact your question is: what can you do to feed a client with all data that are potentially required for user actions at any time? I see three or four options:

1. The standard way to enable access to navigation properties of entities after context disposal is calling Include: from o in db.Objects.Include("Armatuur.Producer")... But that’s clearly not an option for you.

2. Let the context live and rely on lazy loading to fetch data on demand. This may be an option for you. But long-lived contexts may cause problems like gradually declining performance as the internal change track record grows, and stale cached data giving rise to refresh/reload statements scattered all over the place.

3. In stead of navigation properties/lazy loading fetch data on demand from a service/repository layer that uses context instances per call. I think this option could work well for you.

4. More a functional than a technical option: design use cases that can do with less data (so that Include may suffice after all). No one can take in a grid with thousands of rows and tens of columns. Well-designed user interaction can drastically reduce the amount of data that is pumped into a client (and I’m only at the beginning of getting this).