self tracking pocos, how to tell if a property has changed?

((IObjectWithChangeTracker)user).ChangeTracker.State s开发者_JAVA百科eems to give me "Unchanged" every time. When I call ApplyChanges everything is picked up properly, but I would like to be able to make a determination in my business layer on whether someone has a changed a particular property, if they did I want to perform an action.

UPDATED

I believe this has to do with the fact that I don't always serialize my entities which only then triggers the change tracking. I am using them in a asp.net scenario where from time to time I will persist them (serialize) into session state or viewstate.

UPDATED

Added more information in the answer at the bottom of this page.

Several options, each with ups and downs:

• You could keep a private "original" value on your domain objects. Populate them when you get an object from the DB, and then you can easily check if each field equals its original value. This could get cumbersome on large objects, however.

• Another option is to have your domain implement ICloneable, and keep a deep copy of the original object in your data access layer, along with logic to pull it up. The deep copy would still be mutable, so you have to take care not to modify it, and it doubles your memory footprint.

• You could simply re-retrieve the record as a new instance, and check its fields. This is simple and relatively straightforward, but requires two trips to the DB.

• Lastly, if you're using an ORM like NHibernate, you can usually plug into the logic it uses to determine what data has changed. This is the best place to do auditing and other observational behaviors on your domain layer, but it requires use of an ORM that supports this, and you'll have limited ability to change the data.

You could try hooking the OnPropertyChanged event for the property.

To answer my own question (I also updated the original question with the answer) self tracking POCOs only "start" tracking their own changes when they are de-serialized the first time. The original intent is for WCF scenarios for example. In my situation I am using the in ASP.NET often without using serialization at all, which is why the change tracking never kicked in. In most scenarios (in my case) I wouldn't even need the self tracking POCOs, as regular POCOs would have worked just fine. Reason being that even though my entities leave the scope of the repository that contains the context that fetched them, the context is still alive in kicking for the duration of the entire HTTP request. Therefor when I do a subsequent call to the repository to persist changes made the context is still aware of the entity because it fetched it to begin with (earlier in the same HTTP request). The situation in which the self tracking part becomes useful is that when I want to persist my entity in ViewState or Session, that's where the de-serialization will trigger the self tracking capability which will now be required to persist the changes as the context that will be tasked with the update of this entity would not be the same one as the one that fetched it (different HTTP requests all together).