POCO in the Entity Framework : Part 3 – Change Tracking with POCO

POCO in the Entity Framework : Part 3 ??? Change Tracking with POCO | ASP.NET MVC

Thu, 11 Jun 2009 00:29:24 GMT

PingBack from http://aspmvc.co.cc/2009/06/10/poco-in-the-entity-framework-part-3-%e2%80%93-change-tracking-with-poco/

Third post about POCO, first post about Code Only

Diego Vega — Thu, 11 Jun 2009 01:28:54 GMT

It is always busy here with all the improvements we are doing in Entity Framework to make your code work

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Dmitry — Thu, 11 Jun 2009 05:18:26 GMT

I have a model where POCOs have all properties and methods marked as virtual and the classes have a public default constructor. They inherit from the base Entity class that overrides ToString, Equals and GetHashCode object methods and define a couple of abstract properties. The context has lazy loading and proxy change tracking enabled. The objects have a proxy type at runtime.

I still have to execute DetectChanges() in order for the object state to become modified. Am I missing something?

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

divega@microsoft.com — Thu, 11 Jun 2009 06:22:04 GMT

Dmitry,

In general, the answer is no.

As Faisal explains, the need for the DetectChanges() API comes from the fact that Entity Framework supports plain old CLR objects that are not proxies and therefore do not notify the ObjectStateManager of property changes.

To be even more explicit, you will never need to invoke DetectChanges(), as long as you know that the totality of the entity instances that are being tracked are POCO Proxy instances.

Entity Framework can track changes on graphs made of all the different POCO “kinds” below:

1. POCO Proxies

2. Non-Proxy POCOs

3. POCOs that conform with the Proxy requirements but are actually Non-Proxy instances

Even if your class complies with all the requirement for proxies, you only get #1 when you either

a. Retrieve entities from a query

b. Invoke the new ObjectContext.CreateObject<T>() API.

Otherwise, you end up with #3.

Now, only when the graph of objects you are tracking contains instances of #2 or #3, there are changes that the knowledge in ObjectStateManager won’t stay in sync with the latest changes in the graph.

Then, the behavior of the APIs that Faisal lists in this post depends on the information on the ObjectStateManager, and therefore, there are chances that you might get unexpected results unless you invoke DetectChanges() *before* invoking those APIs.

There are many cases however, in which even if you don’t invoke DetectChanges, things are going to be just fine. This is the case, for instance, if the part of the graph the method needs to reason about is different from the part of the graph previous steps in the program have manipulated.

Finally, SaveChanges() implicitly invokes DetectChanges(). As a result, invoking DetectChanges() explicitly is unnecessary in many simple cases.

Hope this answers the question,

Diego

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Dmitry — Thu, 11 Jun 2009 06:50:14 GMT

Diego,

My issue is I do not seem to be getting POCO proxies. I do get them from a query. I believe I tested this behavior by using GetObjectByKey method as well as LINQ to Entity queries.

I implement transaction auditing in the SavingChanges event handler and it would be nice to know the object state before calling DetectChanges/SaveChanges.

I ended up calling DetectChanges in the beginning of the event handler and then call the overload of SaveChanges that does not invoke DetectChanges. This way I don't have to manually track objects created with the "new" operator.

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

divega@microsoft.com — Thu, 11 Jun 2009 07:17:33 GMT

Hello Dmitry,

Creating a class that is “proxy-able” doesn’t per se provide you proxies. If you use simple instance construction like in

var p = new Product();

… you will get non-proxies. If you need free proxy instances, you have to do something like this:

Var p = context.CreateObject<Product>();

If you are still getting non-proxies after doing this, a common cause is that the collection navigation properties in the type are not of type ICollection<T>. This is also a requirement for change tracking proxies.

Regarding your second point, in SaveChanges, by default, DetectChanges is invoked right before raising the SavingChanges event, so you shouldn't need to call DetectChanges yourself.

If for some reason you want to inspect the state of the ObjectStateManager before DetectChanges (just becasue I am not sure I understood the question correctly), I see two easy alternatives:

1. Override SaveChanges and do the inspection before calling base.SaveChanges

2. Invoke SaveChanges with ~SaveOptions.DetectChangesBeforeSave

Hope this helps,

Diego

ADO.NET team blog : POCO in the Entity Framework : Part 3 – Change Tracking with POCO

DotNetShoutout — Thu, 11 Jun 2009 11:26:51 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Guilgamesh — Thu, 11 Jun 2009 18:45:22 GMT

Hello,

I think the new functionality in EF 4.0 addresses very well some on the limitations of the previous version.

I have some questions, and I hope someone can help me find their answers. I am working on a 3-tiered application, and I would like to use ChangeTracking with POCOs. My questions are:

1. Can the Proxies be serialized by WCF?

2. If Proxies can be serialize, how can it be done?

3. What type should I specify in the signature of the WCF methods?

Thanks,

Guilgamesh

Daily tech links for .net and related technologies - June 11, 2009

Sanjeev Agarwal — Thu, 11 Jun 2009 19:23:57 GMT

Daily tech links for .net and related technologies - June 11, 2009 Web Development Opinionated Input

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Guilgamesh — Thu, 11 Jun 2009 23:19:39 GMT

Hello Sanjeev,

I don't know how to interpret this...

Guilgamesh

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Pagal — Fri, 12 Jun 2009 00:15:55 GMT

Is it possible to get the associated ObjectContext from an EntityObject.

Will the next release (.NET 4??) of Entity Framework provide this in a more fundamental fashion.

Maybe as a property like EntityObject.ObjectContext?

ADO.NET team blog : POCO in the Entity Framework : Part 3 – Change Tracking with POCO

9eFish — Fri, 12 Jun 2009 05:25:13 GMT

9efish.感谢你的文章 - Trackback from 9eFish

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

shawn — Fri, 12 Jun 2009 07:17:39 GMT

I agree with Pagal, having access to the active ObjectContext from within an EntityObject would be extremely helpful.

Using Repository and Unit of Work patterns with Entity Framework 4.0

ADO.NET team blog — Wed, 17 Jun 2009 02:08:52 GMT

If you have been watching this blog, you know that I have been discussing the various aspects of POCO

Using Repository and Unit of Work patterns with Entity Framework 4.0

VS2010学习 — Thu, 18 Jun 2009 08:16:22 GMT

If you have been watching this blog, you know that I have been discussing the various aspects of POCO

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Sly — Thu, 18 Jun 2009 20:38:19 GMT

I like to define interfaces for my entities (IProduct and ICategory). That allows me for easy decoration, replacement, proxying, mocking.

Do you support working with interfaces instead of concrete classes? This way you support lazy-loading and change tracking without having to use virtuals.

Thanks

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Jeff — Thu, 09 Jul 2009 19:05:30 GMT

@Guilgamesh

Proxies cannot be directly serialized with WCF serialization, but there are ways to serialize these entities where the proxy is transformed into a "pure poco" (non-proxy). You wouldn't necessarily want to serialize the proxies with WCF because then the proxy definition would have to be part of your OperationContract. This would tightly couple your client code with your persistence layer and you'd loose some of the goodness you got from using POCO in the first place. What we will have is an attribute you can add to your operation contract that uses a new WCF feature called a DataContractResolver. This attribute will signal to WCF to serialize proxy instances as their base, non-proxy DataContract.

When using pure-POCO classes on the client, you will loose the ability to do change tracking. If your goal is: how do I do change tracking of POCOs accross tiers, I'd look into a solution that uses self-tracking entities, which are still POCO in that they do not have a dependency on the persistence framework, but do have code inside them that knows how to track and report changes. There are other blog posts about self-tracking entity support with the Entity Framework on this blog.

Jeff

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Jeff — Thu, 09 Jul 2009 19:07:33 GMT

@Sly

We do not support mapping to interfaces yet. This request is coming up more and more frequently, though as it does allow some interesting patterns (and proxying).

If we supported interfaces and you wanted EF to do lazy loading/change tracking for you, would your assumption be that we just generate our own implementation of the entire class? How would you inject business logic into the class in this case?

Thanks for the note!

Jeff

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Sly — Thu, 09 Jul 2009 19:53:34 GMT

@ Jeff: Hi, thanks for your answer.

I would code a concrete Product class with all my business logic. The Product class would implement the IProduct interface that I would also define.

I would expect that you decorate (GoF decorator pattern) the IProduct interface to add lazy loading/change tracking. Thus, your code would end-up forwarding all calls to my real product implementation where my business logic is. But you would not know about the Product class, just the IProduct interface.

Thanks

Sly

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

radyo dinle — Sun, 19 Jul 2009 17:44:36 GMT

I agree with Pagal, having access to the active ObjectContext from within an EntityObject would be extremely helpful.

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

divega — Sat, 21 Nov 2009 22:16:35 GMT

@Dmitry, just to clarify: when I previously said that DetectChanges is invoked immediately before the SavingChanges event is raised I actually got it upside down. It happens after, to make sure it captures any change you do in your graph inside the event handler. If you need to use the ObjectStateManager API to iterat through entities, you should invoke DetectChanges yourself inside the SavingChanges handler as you mentioned.

re: POCO in the Entity Framework : Part 3 – Change Tracking with POCO

Ben — Thu, 26 Nov 2009 07:49:07 GMT

Does anybody know how to save an entity object in different context? Here is my code.

NorthwindPocoDatabaseTests t = new NorthwindPocoDatabaseTests();

Product product = t.getProduct("Chai");

t.Finish();

t.Start();

product.UnitPrice = 99;

t.saveProduct(product);

t.Finish();

....

public bool saveProduct(Product p)

{

context.Products.Attach(p);

context.SaveChanges();

return false;

}