Initial POCO Design Screencast


Two guys on the team knocked out this quick screencast of some of the prototype work we’ve been doing around POCO an the State Manager. It’s not a long or in depth screencast, but we’re hoping to inspire some additional feedback. If you prefer to download a copy of the video, you can download a .zip here.


Elisa Flasko
Program Manager, Data Programmability

Comments (11)

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

  2. adriaanp says:

    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.

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

  4. Nullable says:

    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

  5. simmdan says:

    @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

  6. simmdan says:

    @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

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

  8. JamesKovacs says:

    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.

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

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

  11. David says:

    Would be nice to have source code of that project…