none
ObjectContext from DbContext

    Question

  • Hi,

    I seem to keep adding the same line to my code to get the ObjectContext from the DbContext:

          using (var db = new ModelContext())
          {
            var ctx = ((IObjectContextAdapter)db).ObjectContext;
            ...
           }
    

    So instead of repeating the same code, I have added a property to the typed DbContext:

      public class ModelContext : DbContext
      {
        public ObjectContext ObjectContext
        {
          get { return ((IObjectContextAdapter)this).ObjectContext; }
        }
        ...
       }
    
    

    Is it just me, am I missing a trick here, or are others finding the same repetition ?

     

    Thursday, January 13, 2011 4:24 PM

Answers

  • Hi Graham,

    This is great feedback thank you! I don't think we're going to be able to support it in the first RTM but it's definitely something we will look at adding in the future.

    ~Rowan

    • Marked as answer by Graham Hay Tuesday, January 18, 2011 7:55 AM
    Tuesday, January 18, 2011 12:30 AM

All replies

  • i think they had ObjectContext as a property in Ctp4 or ctp3 but then they took it out. I wonder why they took it out as well?

    well seems like there are quite a few functionality for you which you have to access the objectcontext so why not expose that as a property..


    Zeeshan Hirani Entity Framework 4.0 Recipes by Apress
    http://weblogs.asp.net/zeeshanhirani
    Thursday, January 13, 2011 6:40 PM
  • Hi,

    We took out ObjectContext as a public member now that we have more functionality available on DbContext, our intention is that most tasks can be performed directly on DbContext with only advanced cases requiring dropping down to ObjectContext. It would be great to hear what you need to drop down to ObjectContext for.

    ~Rowan

    Thursday, January 13, 2011 10:05 PM
  • Much of this probably just arises from the dynamic nature of my application and my lack of familiarity with the new APIs, but there are a few cases where a method exists on the ObjectStateManager or ObjectStateEntry classes that do not seem to be available on the DbEntry class, e.g. GetModifiedProperties.

    One source of confusion for me was the DbContext.Set methods. I was under the impression that these could only be called during initialisation, but it seems that they can be used at runtime for retrieving an existing DbSet. So for example, to delete an entity where the type is not know till runtime, I thought I would need to use the ObjectContext. But, the entity set can be retrieved dynamically using DbContext.Set(System.Type).

    However, the following code does not work because the entity is an instance of a change tracking proxy and does not have the type of the entity itself:

          using (var db = new ModelContext())
          {
            var myEntity= db.MyEntities.First();
            ...
            var dbSet = db.Set(myEntity.GetType());
            dbSet.Remove(myEntity);
          }
    
    

    But this is more to do with the proxy type, rather than exposing the ObjectContext.

    It would be very useful if methods such as DbContext.Set handled the proxy typing issues internally.

    Thanks

    Friday, January 14, 2011 10:57 AM
  • Hi Graham,

    This is great feedback thank you! I don't think we're going to be able to support it in the first RTM but it's definitely something we will look at adding in the future.

    ~Rowan

    • Marked as answer by Graham Hay Tuesday, January 18, 2011 7:55 AM
    Tuesday, January 18, 2011 12:30 AM
  • Hi Rowan,

    incidentally, I got the above code to work using the static method on ObjectContext:

       using (var db = new ModelContext())
       {
        var myEntity= db.MyEntities.First();
        ...
        var entityType = ObjectContext.GetObjectType(myEntity.GetType());
        var dbSet = db.Set(entityType);
        dbSet.Remove(myEntity);
       }
    
    
    

    But it would still be very useful if methods such as DbContext.Set handled the proxy typing issues internally.

    Regards

    Graham

    Tuesday, January 18, 2011 10:26 AM
  • I am using this for running stored procedures through the DbContext API. So I've got something like this:

        /// <summary>
        /// Retrieve the underlying ObjectContext
        /// </summary>
        public ObjectContext ObjectContext
        {
         get
         {
           return ((IObjectContextAdapter)this).ObjectContext;
         }
        }
    
        public IEnumerable<Subscription> GetAllSubscriptions(Nullable<global::System.Int32> accountID)
        {
          ObjectParameter accountIDParameter;
          if (accountID.HasValue)
          {
            accountIDParameter = new ObjectParameter("accountID", accountID);
          }
          else
          {
            accountIDParameter = new ObjectParameter("accountID", typeof(global::System.Int32));
          }
          
          return this.ObjectContext.ExecuteFunction<Subscription>("GetAllSubscriptions", accountIDParameter);
        }
    

    I really like the DbContext abstraction, but it is also necessary for me to run some stored procedures (with some complex internal SQL logic) that cannot easily be done through the fluent api exposed by DbContext / LINQ to Entities.

    Monday, April 18, 2011 4:36 PM