The EDM Wizard created the FK_Address_Contact association shown in Figure 15-2 when it read the BreakAway database. If you are unfamiliar with how relationships are defined in a database, it will be helpful to read additional details about this.

Figure 15-3 shows a portion of the database diagram for the BreakAway database. The diagram shows the Contact and Address tables as well as a visual representation of the 1:* (One to Many) relationship between Contact and Address. On the Contact side, the symbol for primary key is used because the primary key, ContactID, is used in the definition of the relationship.

Figure 15-3. A primary key/foreign key relationship defined between the Contact and Address tables in the database

The ContactID field in the Address table is a foreign key. The relationship is known as a primary key/foreign key relationship, which is often described and represented as PK/FK. This relationship is defined in a foreign key relationship of the Address table named FK_Address_Contact, as shown in Figure 15-4.

Figure 15-4. The relationship defined by the table that contains the foreign key

The Contact table has no knowledge of this relationship; the relationship and all of its rules (known as constraints) are contained in the FK_Address_Contact key. Figure 15-5 shows the details of this foreign key.

Figure 15-5. SQL Server Management Studio’s property editor for defining a relationship between tables

Although a cascading delete rule is not being used in this case, you could define such a rule so that anytime a contact is deleted all of its related Address records will be deleted automatically. You might expect this to be defined in the Contact table, but instead it is defined in the Address table’s foreign key. To use a cascading delete rule in this case, you would change the Delete Rule in Figure 15-5 from No Action to Cascade.

The EDM Wizard reads all of this information, creates the FK_Address_Contact association, and wires it up to the relevant items in the model.

In addition to the association, a number of other items are created in the model as a result of this relationship:

Although an association is always bidirectional, navigating with properties doesn’t necessarily have to be. An interesting twist on relationships is that you are not required to have a navigation property in your model for every endpoint of a relationship.

As an example, the business logic of your application may define that you will frequently need to navigate from a contact to its reservation, but that you will never have to navigate from a reservation back to the contact, meaning Reservation.Contact and Reservation.ContactReference.Load will never be required, but Contact.Reservations will be useful.

In this case, you could simply delete the Contact navigation property from the Reservation entity. However, you must do this in the raw XML as the Designer does not support deleting Navigation Properties. This won’t impact the association between the two entities, and in an edge case you can always dig into the ObjectStateManager to get from the Reservation to the Contact. The plus side is that when you’re coding or debugging, you won’t have the unnecessary Contact and ContactReference properties constantly in your face.

The native query logic you saw when calling Load also applies to how initial queries are constructed. As you have seen, even if you do not request related data to be loaded, the EntityReference information still needs to be returned. There is a particular query scenario that can result in a surprising native query; however, as you look at it, you’ll see that it does make sense after all.

Imagine two entities: Contact and Address. Each Contact can have zero or one related Addresses (see Figure 15-6).

Figure 15-6. Two entities with a 1:0..1 relationship

In the database, Address contains a foreign key, ContactID, to the Contact table.

When you’re querying for addresses, you use the ContactID field to build the ContactReference.Entity. The native query is simply a query of the Address table. But when you’re querying the Contact table, the Contact entity needs to build the AddressReference.EntityKey. The AddressID does not exist in the Contact table in the database, however, and therefore an additional query of the Address table will be required. Here is a LINQ to Entities query that just requests contacts:

VB
From c In context.Contacts Select con

C#
from c in context.Contacts select c

The native T-SQL query, shown in Example 15-1, includes a query of the Address table involving all the Address table fields to be sure to get whatever fields are required for constructing the EntityKey.

SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Extent1].[Name] AS [Name],
[Extent2].[Id] AS [Id1],
[Extent3].[AddressID] AS [AddressID]
FROM   [dbo].[Contact] AS [Extent1]
LEFT OUTER JOIN [dbo].[Employee] AS [Extent2]
  ON [Extent1].[Id] = [Extent2].[Id]
LEFT OUTER JOIN (SELECT
      [addresses].[AddressID] AS [AddressID],
      [addresses].[street] AS [street],
      [addresses].[contactID] AS [contactID]
      FROM [dbo].[addresses] AS [addresses]) AS [Extent3]
        ON [Extent1].[Id] = [Extent3].[contactID]

Although this may be considered an edge case, imagine what the query would look like in a large model that contains a number of these types of relationships. This means that what you may think of as a simple query could in fact become something much more complex when it becomes a native database query.

Learning to accept relationships as first-class citizens is a challenge for many developers. Associations and the EDM rules that exist because of them are a big point of confusion for many developers who are new to the Entity Framework. Many questions in the forums can be attributed to a lack of understanding of how associations function within the Entity Framework.

The ObjectContext tracks relationships independently of entities. In fact, relationships are instantiated as objects. When you add an Address to the contact’s Addresses EntityCollection, a new object is created to represent that relationship. This object has an EntityState just as an entity does. When you remove an Address from the collection, that relationship object is deleted—it is not removed, but its EntityState is set to Deleted. The Entity Framework resolves these relationships when SaveChanges is called to make the appropriate changes in the database.

Understanding that the ObjectContext manages objects for each relationship that exists between a pair of entities can help you to better understand how the context deals with entities that are detached from the context. Remember that when an entity is detached, the context stops tracking its changes and stops managing its relationships. This is because the context destroys the ObjectStateEntry for that entity and any relationships that are dependent on that ObjectStateEntry.

The Entity Framework has a “golden rule” that it will never do something you didn’t explicitly tell it to do. The Entity Framework’s deferred loading, which you learned about in Chapter 4, is a great example of this, whereby the API won’t make a trip to the database without your explicit instruction.

Because of this rule, there is one form of nonrequested behavior that may surprise you when detaching an entity from the context. The behavior is the result of how the context manages the relationships between entities. If you detach an entity from the context and that entity is part of a graph, the entity also gets detached from its graph because the context can no longer manage its relationship.

The fact that the context manages the relationship objects mandates that an object graph must be completely in or completely out of the ObjectContext. For example, if you have a customer graph that consists of a Customer with Orders and OrderDetails and you detach the Customer from the ObjectContext, the Customer will be disconnected from the rest of the entities in the graph. Because the relationship objects that involved that Customer were destroyed along with the ObjectStateEntry for that object, this means you can no longer traverse from the customer, which is not in the context, to the orders, which are in the context.

Conversely, if you have an entity that is not in the ObjectContext and you join it to an entity that is in the ObjectContext, to follow the rule that the entire graph must be either in or out of the context the detached entity will automatically be attached to the context in order to be part of the graph.

You will see this behavior repeated throughout this chapter as you look at the features and functionality regarding relationships.

Along with ObjectStateManager, Object Services provides a Relationship Manager to perform the tasks pertaining to relationships between entities being managed by the context. The Relationship Manager keeps track of how entities attached to the ObjectContext are related to each other. It’s able to do this with the methods and properties that EntityCollection and EntityReference share through the IRelatedEnd interface, which they both implement. IRelatedEnd’s methods include Add, Attach, and Load, among others. When these methods are called, or when one entity is simply set to another entity’s navigation property (e.g., myAddress.Contact=myContact), the Relationship Manager kicks in.

This may sound complex, but it is necessary so that Object Services has a dependable way to manage the many relationships that could exist at any given time. As you create and delete entities, attach and detach entities, and modify relationships, the Relationship Manager is able to keep track of all of this activity. When it comes time to call SaveChanges, the Relationship Manager plays a role that is just as important as that of ObjectStateManager. All of those updates you witnessed, in which related objects were taken care of automatically, were handled by the Relationship Manager. To have the flexibility that the Entity Framework provides at the coding level, it is necessary to have this complexity at lower levels.

With an understanding of how things are working at the lower levels, interaction with related objects should become much easier to comprehend, anticipate, and implement.

Here’s a geeky test so that you can see how some of the plumbing works. Looking at this in detail will give you a better understanding of how the Entity Framework manages relationships and why some of the rules that might not otherwise make sense exist.

Perform a query against the model that retrieves a single Reservation, as shown in Example 15-2.

VB
Dim res=context.Reservations.First

C#
var res = context.Reservations.First();

Grab the new Unchanged ObjectStateEntries in the context, as shown in Example 15-3.

VB
Dim osm = context.ObjectStateManager
Dim oses = osm.GetObjectStateEntries(EntityState.Unchanged)

C#
var osm = context.ObjectStateManager;
var oses = osm.GetObjectStateEntries(EntityState.Unchanged);

Now take a look at these ObjectStateEntries in the debugger, shown in Figure 15-7.

Figure 15-7. ObjectStateEntries in the C# debugger

You queried for a single entity, but three seem to be in the context. In fact, only the first EntityEntry is an actual entity. It’s the Reservation you queried for, as you can see in Figure 15-8.

Figure 15-8. The ObjectStateEntry for the queried Reservation

The last three EntityEntries are placeholders for the EntityKeys of the related data—for example, the related Contact shown in Figure 15-9.

Figure 15-9. An ObjectStateEntry that is a placeholder for an entity even though the entity is not in the cache

Even if a related entity doesn’t exist in memory, the ObjectContext needs to be aware of any relationships that an existing entity (the Reservation) might have. That’s because of the rule (created to cover all scenarios) that states that when a reservation is deleted, the relationship to its contact must also be deleted. This makes sense when both entities have been pulled into the ObjectContext, but not when only the reservation is in there.

While designing the Entity Framework, its creators decided it was safer to have an all-encompassing rule so that unexpected edge cases wouldn’t result in errors. However, to satisfy the rule that the relationship must be deleted, the relationship must first exist. The pseudoentities were created during the query so that the relationships could be created without developers having to pull down additional data to satisfy the rule.

This is why these extra entries exist—one for the Contact, one for the related Trip, and one for the UnpaidReservation entity (which you created in Chapter 13). If the true entity is brought into the context at some point, the Entity value of the entry will be updated. A private property for these entries denotes them as EntityKeyEntries; however, you won’t see that name displayed in the debugger.

As you read through this chapter, this knowledge will help you better understand some of the rules and behavior surrounding relationships.

On their own, navigation properties are almost meaningless. They are completely dependent on an association to provide access to related data. The navigation property does nothing more than define which association endpoint defines the start of the navigation and which defines the end.

A navigation property is not concerned with whether the property leads to an entity or an EntityCollection. The multiplicity in the association determines that, and the results are visible in the object instances where the navigation property is resolved. The property is resolved either as an entity plus an EntityReference, as with the Contact and ContactReference properties of the Address entity in Figure 15-10, or as an EntityCollection, as with the Addresses property of the Contact entity. You can also see this by looking in the generated classes for the model. The Entity Framework still needs to make this determination as it is materializing objects from query results, and then populate the objects correctly.

Figure 15-10. Resolving navigation properties as entities, EntityReferences and EntityCollections

EntityReference properties

Navigation properties that return Entity and EntityReference properties need to be addressed together because they come as a pair, even though both may not be populated. When the navigation property points to the “one” or “zero or one” side of relationship of a 1:1 or 1:* relationship, that property is resolved as two public properties. One property contains the actual entity, and the other property contains a reference to the entity. This reference contains the related entity’s EntityKey, which is relative to a foreign key in a database. The EntityKey provides just enough information about that entity to be able to identify it when necessary. When you execute a query that returns addresses, the ContactID from the Addresses table is used to construct the EntityKey for ContactReference. Even if the contact does not exist in memory, the ContactReference property provides the minimal information about the Contact that is related to the Address.

EntityReference.Value

The value object of an EntityReference shows up in two places. The first is the navigation property (Reservation.Customer) and the second is within the EntityReference property (Reservation.CustomerReference). You can see this in Figure 15-11, where the Customer is loaded into the ObjectContext and therefore is hooked up with the Reservation entity.

Figure 15-11. The Customer property of the Reservation entity as the actual property and as the value of the EntityReference property, CustomerReference

What if there is no EntityReference

In many scenarios, the “one” side of a relationship is required, such as the constraint in the BreakAway model that says a reservation can’t exist without a related customer. However, in some relationships the target is 0..1, meaning the related end isn’t required (e.g., if a customer’s preferred activity does not need to be specified). In the case where there is nothing on that end, the navigation property (Customer.PrimaryActivity) will be null. The EntityReference will exist, but its EntityKey and Value will be null (Nothing in VB), as shown in Figure 15-12 and Figure 15-13.

Figure 15-12. An unpopulated EntityReference, which will have no EntityKey and Value

Figure 15-13. The VB debug view of the empty EntityReference

MyContact.Addresses=myAddressEntityCollection

It is possible to place constraints in both the database and the EDM to ensure the integrity of the data. The point at which these constraints are checked in the pipeline varies.

Many developers approach the Entity Framework with the assumption that these constraints will be checked when their code is manipulating the entities. For example, if you delete an order, when you call ObjectContext.DeleteObject it would be nice to have the Entity Framework tell you “Hey, there are still line items for this order. You can’t do that.”

VB
Dim add = Address.CreateAddress(0, "Home", Now())
context.AddToAddresses(add)

C#
var add = Address.CreateAddress(0, "Home", Now());
context.AddToAddresses(add);

Entities in 'BAEntities.Addresses' participate in the 'FK_Address_ContactSet'
relationship.
0 related 'Contact' were found. 1 'Contact' is expected.

Most databases support cascading deletes, which are used to automatically (and unquestionably) delete all of the children of a parent when that parent record is deleted. Cascading deletes are supported in the Entity Framework as well, but with caveats.

The biggest caveat is that the Entity Framework can perform cascading deletes only on objects that are in memory. This could cause problems if a database constraint is enforcing referential integrity, and if the database does not also have a cascading delete set up on the same set of data. In this case, if the database still contains children, an error will be thrown.

<Association Name="FK_SalesOrderDetail_SalesOrderHeader_SalesOrderID">
  <End Role="SalesOrderHeader"
       Type="AdventureWorksLTModel.SalesOrderHeader" Multiplicity="1">
    <OnDelete Action="Cascade" />
  </End>
  <End Role="SalesOrderDetail"
       Type="AdventureWorksLTModel.SalesOrderDetail" Multiplicity="*"/>
  <ReferentialConstraint>
    <Principal Role="SalesOrderHeader">
      <PropertyRef Name="SalesOrderID" />
    </Principal>
    <Dependent Role="SalesOrderDetail">
      <PropertyRef Name="SalesOrderID" />
    </Dependent>
  </ReferentialConstraint>
</Association>

VB
Using context As New AWLTEntities
  Dim ord = context.SalesOrderHeader.Include("SalesOrderDetail").First
  context.DeleteObject(ord)
  Dim oses = context.ObjectStateManager.GetObjectStateEntries _
             (EntityState.Deleted)
  context.SaveChanges
End Using

C#
using (AWLTEntities context = new AWLTEntities ())
{
  var ord = context.SalesOrderHeader
                   .Include("SalesOrderDetail").First();
  context.DeleteObject(ord);
  var oses = context.ObjectStateManager
                   .GetObjectStateEntries(EntityState.Deleted);
  context.SaveChanges();
}

The simplest way to create relationships between entities is to create the relationship the CLR way—by setting one entity as the property of another entity:

MyAddress.Contact = myContact

If you are starting with the child entity (e.g., MyAddress), this is pretty obvious. But if you are starting with the contact and you want to add the address to its collection, there’s no reason not to switch your perspective and simply set the address’s Contact property. It’s simpler and has the same effect.

This covers the most common scenarios, though you should be aware of the following subtleties:

If you want to populate an EntityReference but you do not have an entity in hand, you can create the EntityReference using only an EntityKey. This requires that you know the value of the EntityReference’s key. And in fact, you did this when creating reservations in some of the example applications earlier in the book.

This allows you to create a foreign key for an entity without having the related data in memory. For example, in the customization you made to SavingChanges, you used an EntityReference to set the default CustomerType of a new Customer. Example 15-6 shows the relevant code from that method.

VB
cust.CustomerTypeReference.EntityKey =
 New EntityKey("BAEntities.CustomerTypes", "CustomerTypeID", 1)

C#
cust.CustomerTypeReference.EntityKey =
 new EntityKey("BAEntities.CustomerTypes", "CustomerTypeID", 1);

This is especially handy, because although you can set default values for scalar properties in the model, it’s not possible to set a default value for a navigation property. By setting the CustomerTypeReference.EntityKey, you can define the CustomerType without having to load the actual CustomerType object into memory. When the Customer is saved, the CustomerTypeReference is resolved, and in the database the Customer record has its CustomerTypeID foreign key value set to 1.

There are a number of ways to populate navigation properties using methods provided by the IRelatedEnd interface, which EntityCollection and EntityReference implement. Depending on the type (collection or reference) from which you call the methods, the Entity Framework performs slightly different methods in the background to achieve the goal.

Examples:

You can call Load from entities that are attached to the ObjectContext. Calling Load will cause a query to be created and executed to retrieve the related data that Load requested. If you have a Contact and call Contact.Addresses.Load, all of the addresses belonging to that contact will be retrieved from the database.

One condition allows you to call Load from detached entities: when the entity was created as a result of a NoTracking query. Example 15-7 calls Load on a Detached entity.

VB
Dim query = context.Reservations
query.MergeOption = Objects.MergeOption.NoTracking
Dim res = query.First
res.CustomerReference.Load()  '<--succeeds

C#
var query = context.Reservations;
query.MergeOption= System.Data.Objects.MergeOption.NoTracking;
var res = query.First();
res.CustomerReference.Load(); //<--succeeds

However, if you detach an entity from the context, calling Load will cause an exception to be thrown, as shown in Example 15-8.

VB
Dim query = context.Reservations
Dim res = query.First
context.Detach(res)
res.CustomerReference.Load()  '<--InvalidOperationException

C#
var query = context.Reservations;
var res = query.First();
context.Detach(res);
res.CustomerReference.Load();  //<--InvalidOperationException

VB
Dim newAddress = Address.CreateAddress(0, "Home", Now())
context.AddToAddresses(newAddress)
newAddress.ContactReference.EntityKey = _
   New EntityKey("BAEntities.Contacts", "ContactID", 100, Nothing)
newAddress.ContactReference.Load()  '<--InvalidOperationException

C#
var newAddress = Address.CreateAddress(0, "Home",Now);
context.AddToAddresses(newAddress);
newAddress.ContactReference.EntityKey =
 new EntityKey("BAEntities.Contacts", "ContactID", 100);
newAddress.ContactReference.Load(); //<--InvalidOperationException

SELECT * from Contact WHERE ContactID=100

VB
Dim firstPayment = context.Payments.First
firstPayment.ReservationReference.Load()

C#
var firstPayment = context.Payments.First();
firstPayment.ReservationReference.Load();

SELECT 1 AS [C1],
[Extent2].[ReservationID] AS [ReservationID],
[Extent2].[ReservationDate] AS [ReservationDate],
[Extent2].[ContactID] AS [ContactID],
[Extent2].[EventID] AS [EventID]
FROM  [dbo].[Payments] AS [Extent1]
INNER JOIN [dbo].[Reservations] AS [Extent2]
    ON [Extent1].[ReservationID] = [Extent2].[ReservationID]
WHERE ([Extent1].[ReservationID] IS NOT NULL)
   AND ([Extent1].[PaymentID] = @EntityKeyValue1)

Parameter: @EntityKeyValue1=1

VB
Dim firstRes = context.Reservations.First
firstRes.Payments.Load()

C#
var firstRes = context.Reservations.First();
firstRes.Payments.Load();

SELECT AS [C1],
[Extent1].[PaymentID] AS [PaymentID],
[Extent1].[PaymentDate] AS [PaymentDate],
[Extent1].[Amount] AS [Amount],
[Extent1].[ModifiedDate] AS [ModifiedDate],
[Extent1].[PaidinFull] AS [PaidinFull],
[Extent1].[ReservationID] AS [ReservationID]
FROM [dbo].[Payments] AS [Extent1]
WHERE ([Extent1].[ReservationID] IS NOT NULL)
AND ([Extent1].[ReservationID] = @EntityKeyValue1)

Parameter:
@EntityKeyValue1=1

Example:

You use Add to add items to an EntityCollection. You can use Add only on EntityCollection. It isn’t valid with EntityReference.

Again, because of the varying states of an entity, you can use Add in a few different ways.

VB
Using context As New BAEntities
  Dim con = (From c In context.Contacts.Include("Addresses")).First
  Dim newAdd = Address.CreateAddress(0, "home", Now);)
   With newAdd
      .Street1 = "1 Main"
      .City = "Hamburg"
      .StateProvince = "NY"
    End With
  con.Addresses.Add(newAdd)
End Using

C#
using (BAEntities context = new BAEntities())
{
  var con = (from c in context.Contacts.Include("Addresses") select c)
            .First();
  var newAdd = Address.CreateAddress(0, "home", Now);
  newAdd.Street1 = "1 Main";
  newAdd.City = "Hamburg";
  newAdd.StateProvince = "NY";
  con.Addresses.Add(newAdd);
}

Adding entities to the EntityCollection of a detached object

If the calling entity is detached from the context, Add will be treated as a CLR method, as shown in Example 15-15.

Example 15-15. Adding to the EntityCollection of a detached entity

VB
Dim firstRes = context.Reservations.First
context.Detach(firstRes)
Dim newPayment = New Payment
newPayment.Amount = 100
firstRes.Payments.Add(newPayment)

C#
var firstRes = context.Reservations.First();
context.Detach(firstRes);
var newPayment = new Payment();
newPayment.Amount = 100;
firstRes.Payments.Add(newPayment);

In this case, the newPayment entity will be added to the Payments collection and you’ll be able to navigate from the Payment to the Reservation (newPayment.Reservation). But because the ObjectContext is not involved, no Relationship object is created, and therefore newPayment.ReservationReference.EntityKey will be null, as shown in Figure 15-14.

Figure 15-14. A new entity that was added to the EntityCollection of a detached entity

Examples:

In addition to ObjectContext.Attach, an Attach method exists for IRelatedEnd, which you can use for EntityCollections and EntityReferences.

Using the Attach method, you can define relationships between entities that already exist in the ObjectContext but that have not been connected automatically.

EntityCollection.Attach is more commonly used than EntityReference.Attach. Although it is technically possible to use the latter, it is not generally necessary because it is so much easier to merely assign the EntityReference value.

EntityCollection.Remove is used to remove an entity from a collection. It will stay in the ObjectContext, but will no longer be related to a parent in that particular association. There is no Remove method for EntityReference.

Whether you are calling Attach or Add from ObjectContext or from IRelatedEnd, it’s important to understand the difference between these two methods.

Add will create an ObjectStateEntry with EntityState=Added. If you are using the ObjectContext.Add method, the EntityState is impacted on the entity that you are adding. If you are calling the EntityCollection.Add method, it is the relationship whose EntityState is affected. When SaveChanges is called the entity that was added to the context will be inserted in the database and the relationship that was created will be persisted in the database.

Attach will create an ObjectStateEntry whose EntityState=Unchanged. If you are calling the ObjectContext.Attach method, the resulting ObjectStateEntry will have a clean slate. SaveChanges will do nothing with that entity. If you are calling EntityCollection.Attach, a RelationshipEntry will be created and it will have a clean slate. Nothing will happen with respect to this relationship when SaveChanges is called.

When you use the CLR properties to set the entity value, Add and, if necessary, Remove are called under the covers.

Often you will want to move an entity from one graph to another, perhaps for the simple reason that an end user applied a payment to the wrong reservation.

In such a case, you can simply reassign the Reservation property:

myPayment.Reservation=myReservation

or add the payment to the Payments EntityCollection of the new reservation:

myReservation.Payments.Add(myPayment)

The ObjectContext will resolve the existing relationship. If you were to inspect the relationships in the context after the change, you would find a RelationshipEntry linking the payment to the original reservation and another RelationshipEntry linking the payment to the new reservation. The EntityState of the first entry would be Deleted, while the EntityState of the second entry would be Added.

Not only can you attach an entity to an IRelatedEnd, but you can also attach an IEnumerable when you are calling EntityCollection.Attach. An EntityCollection is not an IEnumerable, which is why you can’t just attach another EntityCollection. But if you want to attach a number of entities at once, you can wrap them in something as simple as a list or the results of another query.

Additionally, you can use this as an alternative to EntityCollection.Load because it will give you some flexibility regarding what you are loading. You can use CreateSourceQuery to create queries on the fly for an Attach method, though you’ll use it a bit differently for EntityCollection.Attach and EntityReference.Attach.

The most efficient way to create an IEnumerable for attaching or loading entities into an EntityCollection is to use the CreateSourceQuery method. Like the Load method, CreateSourceQuery will take care of the query creation and execution for you, leveraging the existing ObjectContext.

As an example, if you have a customer in the ObjectContext and you want to get that customer’s reservations, you could call the following:

myCust.Reservations.Load()

This would load all of the reservations for that customer.

However, if you want to filter those reservations, you can use CreateSourceQuery instead, as shown in the following code:

VB
Dim cust=context.Contacts.OfType(Of Customer).First
Dim sq = cust.Reservations.CreateSourceQuery() _
 .Where(Function(res) res.ReservationDate > New Date(2008, 1, 1))
cust.Reservations.Attach(sq)

C#
var cust=context.Contacts.OfType<Customer>().First();
var sq = cust.Reservations.CreateSourceQuery()
 .Where(r => r.ReservationDate > new DateTime(2008, 1, 1));
cust.Reservations.Attach(sq);

The query will execute when the CreateSourceQuery is called. Now only the subset of reservations for that customer will be loaded.

You can also use CreateSourceQuery to filter on types. In the following code, Attach is being used with an EntityReference, which will not take IQueryable. Instead, you need to pass in an object, which you can get using the FirstOrDefault query method. Since Attach will throw an exception if you attempt to pass in a null, you need to test for null before calling Attach:

VB
For Each a In addresses
  Dim sq = a.ContactReference.CreateSourceQuery() _
            .OfType(Of Customer).FirstOrDefault
  If Not sq Is Nothing Then
    a.ContactReference.Attach(sq)
  End If
Next

C#
var addresses = context.Addresses.Take(5);
foreach (var a in addresses)
{
  var sq = a.ContactReference.CreateSourceQuery()
            .OfType<Customer>().FirstOrDefault();
  if (sq != null)
    a.ContactReference.Attach(sq);
}

With this code, only customers will be loaded.

Foreign keys do not exist in an EDM. Foreign keys from a database table are replaced with navigation properties when an entity is created. Because you can traverse relationships in the EDM without having to perform JOINs, the need for foreign keys is greatly reduced. However, at times you may want to have access to a foreign key value such as Address.ContactID.

Although the value is not exposed directly, if you have the entity or the EntityReference, you can get to that value. For example, if the Address.Contact property is populated, you can simply request Address.Contact.ContactID.

If the ContactReference property is populated, you could drill into the EntityKey and extract the value. Don’t forget that an EntityKey is composed of a collection of key/value pairs. Although a Contact entity may have only one key property (ContactID), in plenty of cases multiple properties are combined to make an EntityKey, just as you can use multiple fields in a database table to create a primary key.

Example 15-16 shows how to retrieve the ContactID from an Address entity.

VB
address.ContactReference.EntityKey.EntityKeyValues _
 .Where(Function(k) k.Key = "ContactID")

C#
address.ContactReference.EntityKey.EntityKeyValues
 .Where(k=> k.Key == "ContactID")

An extension method that can return a foreign key value for any EntityReference would be handy here. A simple approach requires that the developer knows about the EntityReference, and this particular method will presumptuously return the value of the first key, as shown in Example 15-17.

VB
<Extension()> _
Private Function ForeignKey(ByVal entRef As EntityReference) As Int32
  Dim keyval As Int32
  If Int32.TryParse _
    (entRef.EntityKey.EntityKeyValues(0).Value.ToString, keyval) Then
      Return keyval
  Else
    Return Nothing
  End If
End Function

C#
public static class extension
{
  public static int ForeignKey(this EntityReference entRef)
  {
    int keyval = 0;
    if (int.TryParse(entRef.EntityKey.EntityKeyValues[0]
                           .Value.ToString(),
                     out keyval))
      return keyval;
    else
      return 0;
  }
}

Now you can call the extension method like so:

address.ContactReference.ForeignKey()

To write a method that extends the entity and does not require that you first drill into the EntityReference calls for some tricky use of MetadataWorkspace, which you will learn about in Chapter 17.