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: http://www.dnrtv.com/default.aspx?showNum=117
Check it out and let me know what you think.
PingBack from http://blog.a-foton.ru/2008/07/entity-framework-intro-up-on-dnrtv/
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!
Just viewed the two web-casts and unfortunately they didn't really cover much that Linq to SQL supports. Yet I know EF does do much more. However, I guess you have to start somewhere. I was interested in some of the samples however and how you would handle slightly different scenarios (yet common). Ie
Order.Customer = myCustomerObject;
This seems all fine and good if you have the full customer object. However, lets assume for a moment I only have their key (CustomerID). How would I associate this customer with the Order without having to retrieve the entire Customer object (which I dont need)?
Also with the service example, there's an implied knowledge that the user wants to update data. What if I have both new and updated data in my object graph. Ie I'm updating some object and adding a new instance to a child entity etc. In this scenario how would the EF know that its an update unless we did bring back the original entity (which we can't really expect our client to be supplying; as in the example - I get this was done to make it simple) and how far down the tree would we go? I guess my question is how does the EF handle the persistence of child objects of a given entity when we cannot know if they are new (insert) or updates? If it can handle this scenario (and one would hope it does) then why cant that also be applied to the root entity? so that the EF determines if its a new or update to the entity.
Oh based on what was covered; it was well presented :)
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.
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:
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.