views:

68

answers:

1

Hi there,

I wonder if anyone can help me?

I am having problems understanding why i need to issues DetectChanges on my POCO (non proxy) entities.

Of course i have this line to ensure that proxies are not returned.

   context.ObjectStateManager.GetObjectStateEntry(order).State

And doing some research it appears if i need to check the "state" of an object then i need to issue detechChanges But why would i need to check the State of an object?

Basically I send along my POCO entity to a method that SAVES the data to a new ObjectContext (I create and destroy ObjectContext on each method)

Hence, i am having problems understanding why i would need to have ObjectContext track or be aware of changes?

Is it because that if its not aware if will not be saved?

Maybe i am miss informed but it appears that if i am using an existing ObjectContext (which i am not i am creating and destroying each time) that ensure ObjectContext is aware would be beneficial but otherwise not?

So in 1 method I am updating an object by creating a new datacontext, saving it to the db and destroying ObjectContext . Hence i am not using 2 methods, 1 method to send the update or new record and then another method for SAVING.

I would really appreciate any quick explaanations of why its needed?

Thanks in advance

+1  A: 

Your question is little bit confusing. You are writting about Entity Framework but using DataContext which is related to LinqToSql.

The behavior differs in the way you are using ObjectContext. When you load POCO entity from database ObjectContext holds its instance in internal Identity Map. By default POCO doesn't use any kind of change tracking. When you save that POCO entity to the same instance of ObjectContext it internally calls DetectChanges to compare current entity state with stored state. This comparision defines which columns have to be updated. Internal call to DetectChanges is default behavior which can be turned off so you will have to call this method manually.

In your scenario you not using the same instance of ObjectContext. In that case you first have to Attach POCO entity to the ObjectContext. MSDN strictly says that when attaching entity it is marked as Unchanged. For that reason you have to say ObjectContext that entity has changed. You can do that for whole entity or you can define exactly which properties have changed but you have to do it manually = you have to store that information somewhere (Self tracking entities can help you with that but they have ohter disadvantages).

Ladislav Mrnka
Thank you ..., yes .. sorry i made a typo.. its objectcontext not datacontext :-)
Martin
I have updated my question with the corrected typo. Thank you. Maybe i should be using hte same ObjectContext? I have a repository pattern (class) ... and i create a new ObjectContext on every method surrounded by a Using statement so that is created and destroyed.. Maybe i should be creating it as a class level variable.. hence it is created when i create an instance of hte class (repository) and destroyed when the instance no longer exists? Do you think this is a better way forward.??? I read that keep ObjectCOntext alive isn't a godo idea???
Martin
It depends on the type of application and the way you are using repository. Keeping ObjectContext alive for a long time is not a good idea except some scenarios in WinForm or WPF application. But keeping ObjectContext alive for single web request is abolutely OK. Check my other answer why long living and shared contexts are not good idea: http://stackoverflow.com/questions/3653009/entity-framework-and-connection-pooling/3653392#3653392
Ladislav Mrnka
thanks for some great info!
Martin