Comments

# Tim Mallalieu's Blog. said on June 24, 2008 10:08 PM:

We just threw up a screencast on the EF design site to complement the POCO feature design notes. This

# adriaanp said on June 25, 2008 9:21 AM:

Very interesting, I am trying to work out how does the ObjectContext tracks changes, must the objects be added first to the ObjectContext? Surely that would make sense.

# O bruxo mobile said on June 25, 2008 2:48 PM:

Bueno, lo primero es lo primero.... Tengo que decir que he quedado encantado con el evento organizado

# Nullable said on June 25, 2008 10:06 PM:

OK, at first I thought that the video was lame, and provided no help :) (because I was thinking ... "yeah... duh"), but something hit my while watching it. btw, it had nothing to do with what they were doing, other than the fact that when they showed the "Orders" class, they were using fields instead of properties... then it hit me.

If you were to do a snapshot, then compare graphs... that would be a 100% solution, but it's heavy in terms of memory. But I realized that you only have to track properties that are mapped (specifically) in the C-Space!

So, instead of graphing the entire potentially huge class, you could create a realtively small momento of ONLY the fields (and properties) that are mapped back to the DB, then compare them later.

As I'm typing this, I realize that you were probably already thinking that, as the ViewState uses the momento pattern, but I figured I'd mention it anyway.

Peace,

-Timothy Khouri

# dsimmons@microsoft.com said on June 26, 2008 12:08 AM:

@adriannp,

Yes, the objects need to be added to the context.  In general this will work the same as it does with prescriptive entities in EF v1: by default entities will be associated with the context if they are materialized as part of a query, and if you create instances through some other mechanism, then you would either need to add them as new objects with the Add method or to Attach them in the unchanged state.

- Danny

# dsimmons@microsoft.com said on June 26, 2008 12:11 AM:

@Nullable,

Yes, this is the general mechanism we're thinking about.  The ObjectStateManager already has a mechanism for storing original values of the properties of an entity which are mapped to the database.  In EF v1 these are only stored on write when the entity notifies the framework of a change.  In v2 this feature would snapshot all the persisted values when the entity was first attached to the context (if it doesn't implement the change tracking interface used in v1).

- Danny

# Eric and the .NET Framework said on July 8, 2008 9:31 AM:

The ADO.NET Entity Framework is very strategic to Microsoft - but a) it is a V1.0 technology (although

# JamesKovacs said on July 15, 2008 1:22 PM:

I noticed in the video that your POCO entities used public fields, which is not typical in .NET development. How do you handle mapping to properties? Can you map to properties with a public getter and either a private or no setter? Are you still using an EDMX file behind the scenes to declare your mapping metadata? I am interested to see how POCO support in V2 shapes up including lazy loading for collections and properties.

# system.data.objects dev guy said on August 10, 2008 4:09 AM:

Entity Classes & Architecture Patterns Part of the Entity Framework FAQ . 2. Architecture and Patterns

# system.data.objects dev guy said on August 10, 2008 4:12 AM:

Entity Classes & Architecture Patterns Part of the Entity Framework FAQ . 2. Architecture and Patterns

# David said on February 14, 2009 1:38 AM:

Would be nice to have source code of that project...

Leave a Comment

Name (required) 

Your URL (optional)

Comments (required) 

  

Enter Code Here: Required

Remember Me?