Share via

Entity Framework Intro up on dnrTV

  • Article

I recently recorded a couple of dnrTV episodes which give some basic introduction to parts of the Entity Framework.  It's my hope that these will help people quickly get some ideas about what the EF can do and how to get started using it.  The first episode is up now at: <www.dnrtv.com/default.aspx?showNum=117>

Check it out and let me know what you think.

 - Danny

Comments

  • Anonymous
    July 13, 2008
    PingBack from http://blog.a-foton.ru/2008/07/entity-framework-intro-up-on-dnrtv/

  • Anonymous
    July 14, 2008
    Thanks for doing a webcast at dnrtv. Hopefully you would pick up on this series and do 3 or 4 more so that people like me who want to migrate to entity framework from linq  can easily transition. By the way, the comments you made on blog post were really helpful and helped me understand why things worked differently in linq and entity framework. I think entity framework is great but all of us are dying for some upgrades to linq to sql as well such as many to many tables, allowing cylces basically a simpler option like entity framework has for loading self referencing tables and good support for serialization for linq to sql classes. Thanks and keep up the good work!

  • Anonymous
    August 03, 2008
    The comment has been removed

  • Anonymous
    August 03, 2008
    Your first question is easy: If you want to setup a relationship from an order to a customer when you only have the customer key (and you don't want to make a database roundtrip to retrieve the customer object), you can set the EntityKey property on the CustomerReference on the order.  That is:     Order.CustomerReference.EntityKey = myCustomerKey; When it comes to the second question, though, things are more difficult.  The EF doesn't have a mechanism to automatically determine if something is updated or new.  You need a mechanism to make that determination--which could be adding a serializable property to the entities which tracks their state, or it could be tracking information on the outside somehow.  You can get some ideas from a series of posts here on my blog about entitybag which was just an exercise to explore these issues. Tracking changes on the client and communicating them back to the web service is something which must be handled, but often it's not that bad.  It turns out that the harder part usually is breaking the graph up into those parts which are modified, those which are unmodified and those which are new.  This is required because the object services operations like add and attach operate on an entire graph at once and perform the same operation.   There's a long story behind this behavior which I won't go into here, but suffice it to say that even though there were some good reasons behind it, the usability of some of these scenarios is not what we'd like.  We're working on some improvements for v2 which should help with these scenarios.  For now your best option is probably to create a contianer something like entitybag which separates a graph of related entities into separate lists of individual entities in various states and also stores relationship info separately--that way you can easily play those changes back into the context in order to persist them.

  • Danny
  • Anonymous
    August 06, 2008
    Thanks for the clarification. Though I find the CustomerReference property somewhat ugly, as its not very natural. However, I understand this is not a simple issue to address. I'd be interested in your thoughts (positive or negative) on the technique I discussed here: http://www.dotnetprofessional.com/blog/post/2008/06/Modeling-many-to-one-(M1)-entity-relationships-Part-I.aspx As for the second part, this could be a deal breaker. If I'm building a service (web or otherwise) how am I supposed to save an object graph when I can't know upfront that the entity is a new or edited one? For single entities its not too bad, as the end user can pick the appropriate service. However when we deal with object graphs this becomes quite difficult, depending on how you define your keys. If they are identities then maybe not too bad as a null or zero would tell you its a new record. However, if you're using Guids (which would be recommended as the exposed key) then its going to take a fair bit of effort to track this. Worse yet, is the server can't really track it for you without first asking the db if the Guid exists. Still I don't believe the EF is alone with this issue. Personally I dont like the context concept because of these issues.