Programming Entity Framework - Cdn.oreilly.com

More documents

Recommendations

Info

POCO objects do not communicate back to the context. Therefore, the context needs at some point to take a look at the POCO objects and synchronize their data with the ObjectStateEntry objects which represent them. The ObjectContext class has a method called DetectChanges that satisfies this purpose. Understanding the Importance of DetectChanges It is important to instruct the context to detect changes prior to constructing the various SaveChanges commands when you want to send any changes made to your POCO objects to the database. Otherwise, the ObjectStateEntry objects that the context is managing will not reflect the changes and no insert, update, or delete commands will be sent to the data store. You may recall from Chapter 5 that one of the SaveOptions parameters for SaveChanges is DetectAllChanges. That option will force the context to call DetectChanges prior to the save logic. The default behavior for SaveChanges is that it will call DetectChanges, so you do not need to explicitly call the method or set the SaveOptions enum. Exploring and Correcting POCOs’ Impact on Two-Way Relationships In addition to syncing up the ObjectStateEntry objects, the context will force the POCO classes to be aware of any two-way relationships. With an EntityObject class, if you add an address to the contact.Addresses EntityCollection, not only does that impact the Addresses property, but you also automatically get the twoway relationship fix-up. As a result, Address.Contact is also populated. The twoway relationship also works in the other direction. If you assign a contact instance to Address.Contact, that contact also recognizes that address in its Addresses EntityCollection. However, this doesn’t automatically happen with the POCO objects. Let’s modify the earlier code to see what happens when you build relationships with POCO objects. Add the code in Example 13-5 below the last line of code in Example 13- 4. That line is included here for placement reference. Example 13-5. Experimenting with two-way relationships int addressCount = firstContact.Addresses.Count(); //new code begins here Address newAddress = new Address { Street1 = "1 Main Street", City = "Mainville", StateProvince = "Maine", ModifiedDate =DateTime.Now }; firstContact.Addresses.Add(newAddress); addressCount = firstContact.Addresses.Count; Contact newAddressContact = newAddress.Contact; //new code ends here
} If you run the code now, you will find that newaddressContact is null because the POCO classes don’t comprehend the two-way relationship. You added the address to the contact’s collection of addresses, but you did not add the contact to the address. There are three ways to solve this problem. The first relies on the ObjectContext to fix the relationship using the ObjectContext.DetectChanges method. The second is to give the classes themselves the intelligence to automatically assign the alternate relationship at the time that you modify the property. The last involves virtual (overridable in VB) properties and proxies, which will be explained on the following pages. It’s possible that you do not want two-way relationships. In fact, you may not want to be able to navigate from address to contact. You can easily control this with the existence or accessibility of the setters and getters in the POCO classes. For this example, you will support the two-way relationship and automatic fix-up. Using the DetectChanges Method to Fix Relationships Modify the example by adding the following code just before the code line which assigns newaddressContact: context.DetectChanges(); Run the code again and you should see that the address is now aware of its contact. Be careful how you use this method. You do not want to automatically call DetectChanges anytime you assign a relationship, because it will process every entity that is being tracked by the context. Implement it explicitly if you really need to be aware of the two-way relationship anytime prior to saving changes. You may prefer to put the onus on the classes themselves to do the fix-up. Enabling Classes to Fix Their Own Relationships The other fix-up path lets the classes be responsible for fixing their relationships. There are varying definitions surrounding the purity of POCO classes. Some developers would find it undesirable to have one POCO class affect the properties of another, and therefore would not approve of this method. First we’ll attack the Contact class’s Addresses property. Unless you want to create a new type of collection class, the simplest thing to do is to create an explicit method in the Contact class which you can call AddAddress. Example 13-6 displays the pattern for this method. First you’ll need to instantiate the Addresses if it has not yet been instantiated. Then you can add the new address after verifying that it does not already exist in the collection. So far, this only adds the address to the Contact’s collection. Finally, it is time to “fix up” the relationship by ensuring that the address will also know about its contact. The code comment about the circular reference will make more sense after you modify the Contact class.
Page 1 and 2: Free Sampler
Page 3 and 4: Programming Entity Framework by Jul
Page 5 and 6: The EDM Within the Entity Framework
Page 7 and 8: Retrieving a Single Entity with Get
Page 9 and 10: Breaking Apart the ObjectQuery 222
Page 11 and 12: Using a New EntityDataSource to Add
Page 13 and 14: Insert, Update, and Delete Function
Page 15 and 16: Digging Through ObjectStateEntry 53
Page 17 and 18: 19. Using Your Own Custom Classes .
Page 19 and 20: Designing the Service Interface 725
Page 21 and 22: In addition to POCO support, the te
Page 23 and 24: using System.Text; namespace Chapte
Page 25: } } public ObjectSet Addresses { ge
Page 29 and 30: Using Proxies to Enable Change Noti
Page 31 and 32: Figure 13-2. A high-level view of t
Page 33 and 34: Rule 2: To enable lazy loading on a
Page 35 and 36: using System.Collections.ObjectMode
Page 37 and 38: Modifying the POCO Template Althoug
Page 39 and 40: The next step is to modify the temp
Page 41 and 42: get; set; } public string Street1 {
Page 43: Want to read more? You can find thi

Programming Entity Framework - Cdn.oreilly.com

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?