Let’s replace the navigation that the Entity Data Model Wizard created between Contact and Customer with an inheritance hierarchy that maps back to the database tables.

When the inheritance is set up, the Customer entity will have a glyph at the top that indicates it is inheriting from Contact. There is an inheritance line between the two entities as well, with the arrow pointing to the base entity (see Figure 12-3).

Figure 12-2. Defining an inheritance between Contact and Customer

Figure 12-3. The new inheritance displayed in the model

Because the Customer’s ContactID was deleted so that it can now inherit from Contact, a number of the mappings for associations involving Customer were broken. If you compile the model, you’ll find a list of mapping errors. The associations still exist, so you’ll need to remap the associations.

The Customer entity has six associations defined with other entities. This will be a good lesson in mapping associations, because this task is not very intuitive in the Designer.

Select the association between Customer and CustomerType. You’ll see that the CustomerTypeID mapping is still in place, but the ContactID mapping to the Customers table is gone. Select ContactID in the drop-down under Column to map from the ContactID property, as shown in Figure 12-4.

Figure 12-4. Remapping the ContactID in the association between Customer and CustomerType

Remap the ContactID property in the association between Customer and Reservation.

Although you could edit the existing mappings for the associations, you will be better off completely removing and re-creating the four associations between Customer, Activity, and Destinations. As you delete the associations, the navigation properties will also disappear. Don’t worry; they will return as you re-create the associations.

There are two associations between Customer and Activity. In the following exercise, you will create the first Activity association and mapping:

Figure 12-5. Multiplicity for the association

Figure 12-6. Association mapping for PrimaryActivity

Now you can create the second mapping between Customer and Activity. To begin, add another association between Customer and Activity. Follow steps 1–4 in the preceding exercise, but this time change the navigation properties to SecondaryCustomerPrefs and SecondaryActivity, fix the multiplicity, and then map the association to Customers.SecondaryActivity and Customers.ContactID.

Follow steps 1–4 again to remap the associations used for the Customer’s PrimaryDestination and SecondaryDestination properties. The navigation properties for the first association will be PrimaryCustomerPrefs and PrimaryDestination. This association will map to the Customers.PrimaryDestination property. The navigation properties for the second association will be SecondaryCustomerPrefs and SecondaryDestination. This association will map to the Customers.SecondaryDestination property.

Both the Customers and the Contact tables have a TimeStamp column for concurrency checking. However, because the Customer is inheriting all of the properties of Contact, the Customer now has two TimeStamp properties. To avoid conflict, change the name of the Customer’s TimeStamp property to custTimeStamp. In Chapter 18, you’ll learn more about concurrency with inherited types.

As a result of the inheritance, the Customer object inherits the Contact properties. You no longer need to navigate to Contact to get the Customer’s LastName, FirstName, or other Contact properties. You can also navigate directly to the Addresses EntityCollection through the Addresses property.

In the model, this means the Customers EntitySet is now gone, and Customer is served up from the Contacts EntitySet. When you request Contacts, those Contacts that have a Customer entity will be returned as Customer types.

To query for customers specifically, you will need to use the OfType method to specify which type of contact you are seeking, as shown in the following code:

VB
From c in Contacts.OfType(Of Customer) Select c

C#
from c in Contacts.OfType<Customer> select c;

You’ll see many more examples of querying types in an inheritance hierarchy throughout this chapter and the rest of the book.

To test this new TPT inheritance, as well as the various customizations you will be creating further on in this chapter, create a new Console Application project and then follow these steps:

VB
Imports BAGA.BreakAwayModel

C#
using BAGA.BreakAwayModel;

Let’s see the inheritance in action.

When debugging the Customer results, you can see that the Customer has inherited the LastName and FirstName properties of Contact. When debugging the Contact results, you can see that only the Contact properties are there, even for contacts who are customers.

Finally, looking at the counts displayed in the output, you’ll find that the number of queried customers is much smaller than the number of contacts, and is, in fact, a subset of contacts.

In Example 12-1, a Customer was created in memory, added to the context, and then saved to the database with context.SaveChanges. When SaveChanges is called, the Entity Framework constructs commands to first create a new Contact record, and then, based on the newly generated ID returned from the database, to create the Customer record.

Example 12-2 shows the two commands executed on the database as a result of the code in Example 12-1. The first inserts a contact and does a SELECT to return the new ContactID and TimeStamp. The second inserts a new Customer using the new ContactID, 851.

exec sp_executesql
N'insert [dbo].[Contact]([FirstName], [LastName],
  [Title], [AddDate], [ModifiedDate])
  values (@0, @1, null, @2, @3)
  select [ContactID], [TimeStamp]
  from [dbo].[Contact]
  where @@ROWCOUNT > 0 and [ContactID] = scope_identity()',
N'@0 nchar(4),@1 nchar(7),@2 datetime2(7),@3 datetime2(7)',
  @0=N'Noam',@1=N'Ben-Ami',@2='2008-10-23 14:07:33.7290000',
  @3='2008-10-23 14:07:34.6000000'

exec sp_executesql
N'insert [dbo].[Customers]([ContactID], [CustomerTypeID], [InitialDate],
  [PrimaryDesintation], [SecondaryDestination], [PrimaryActivity],
  [SecondaryActivity], [Notes])
  values (@0, @1, null, null, null, null, null, null)
  select [timestamp]
  from [dbo].[Customers]
  where @@ROWCOUNT > 0 and [ContactID] = @0',
N'@0 int,@1 int',@0=851,@1=1

Notice that the AddDate and ModifiedDate have values in the Contact insert, and the Customer insert has a value for CustomerTypeID. These values are coming from the custom SavingChanges event you built in the preceding chapter. The new Customer record is seen as both a Contact type and a Customer type. Therefore, as SavingChanges tested for the entity type and populated values based on that, the new Customer entity got the required values for Contact and for Customer.

You can explicitly query for different types within an inheritance structure. To specify a derived type with LINQ or Object Services you can append the OfType method to the entity set being queried:

VB
Context.Contacts.OfType(Of Customer)

C#
Context.Contacts.OfType<Customer>

You can do this in a variety of other ways in LINQ, as well.

In Visual Basic, you can use the TypeOf operator for type filtering:

VB
From c In context.Contacts  _
Where TypeOf c Is Customer Select c

From c In context.Contacts  _
Where Not TypeOf c Is Customer Select c

In C#, you can do direct type comparison:

C#
from c in context.Contacts where c is Customer select c;

from c in context.Contacts where !(c is Customer) select c;

Entity SQL also has operators for working with types, and in fact, it can filter out types in a way that is not possible with LINQ to Entities.

The type operators you will use most commonly in Entity SQL are OFTYPE and IS [NOT] OF. The following code snippets represent examples of how you could rewrite the preceding queries with Entity SQL. Note that you could do this by using query builder methods, as well.

To return only Customer types:

SELECT VALUE c
FROM OFTYPE(BAEntities.Contacts, BAModel.Customer)
AS c

To return Contacts which are not Customer types:

SELECT VALUE c
FROM BAEntities.Contacts
AS c
where c IS NOT OF(BAModel.Customer)

There is an additional Entity SQL operator called TREAT AS that allows you to do type casting directly in the Entity SQL expression.

The preceding two Entity SQL expressions will return results that are still shaped like Contacts. To ensure that the results are shaped like the types that you are seeking, you’ll need to use TREAT AS. As with the OFTYPE operator, be sure to use the assembly namespace in the strongly typed name of the type you are casting to.

To return only Customer types that are type-cast as Customer types:

SELECT VALUE TREAT(c AS BAModel.Customer)
FROM OFTYPE(BAEntities.Contacts, BAModel.Customer)
AS c

As you can see, you can also use Object Services and EntityClient with Entity SQL to build more complex queries around types.

In LINQ, the safest way to do type filtering is to use the OfType method, because the rest of the query will know you are working with Customer and not Contact, so you can do any filtering or projection based on Customer properties.

When you place the type filter in the Where clause, the rest of the query is still based on the type being queried—in the preceding example, Contact. You won’t be able to do projection or filtering on Customer properties.

What if you have a contact that becomes a customer? This is an important business rule for BreakAway Geek Adventures, and one that TPT inheritance doesn’t readily support. This isn’t to say that the Entity Framework doesn’t support this scenario, but TPT by definition doesn’t support it.

Let’s look at what may seem like logical options using the Entity Framework, and why they won’t work. The counterpoints provide a lot of insight into the workings of Object Services:

Although you may want to continue banging your head against the wall with creative hacks, the reality is that TPT inheritance does not support this scenario, and even with all of the other benefits that came along with having Customer inherit from Contact, this is a big problem.

Having Customer inherit from Contact is something you should consider prior to designing your EDM. TPT inheritance may be perfect for your business model; it may create some rare annoyances; or it may not be the right way to go at all. These are decisions you’ll need to make.

Given the existing model, the best way to create a Customer for an existing Contact is to use a stored procedure. Not a stored procedure that is wired up to the Customer entity through mappings, but a separate one that can be called explicitly from code. This will allow you to have your cake (the convenience of the derived type) and eat it too (perform functions that TPT inheritance does not support). We will discuss stored procedures in the next chapter, and at that time you’ll see how to leverage the EDM’s flexibility to solve this problem.

In the current inheritance model, the base type, Contact, is instantiated for some entities, and Customer is instantiated for others. It is possible to have base types that are abstract, which means they are there to help define the structure of entities that derive from them, but they will never be instantiated.

If you turned Contact into an abstract type, however, a few hundred contacts (those that are not customers) will never appear in your application because they won’t have an instantiated type to map to. You would have no way to access contacts who are not customers.

To solve this you need to create derived entities to represent other types of contacts.

What would a derived type that accesses the non-customer contacts look like? Let’s modify the model to see:

Now it’s time to create the new derived type:

Remember that because you queried for just the Customers first and then all Contacts, the Customers that were pulled into the cache on the first query will be up front. As you can see in Figure 12-7, when looking at the results in the debugger, you’ll need to scroll down past the Customer entities before you see the NonCustomer entities.

Figure 12-7. A query on the abstract type, Contact, showing all of the derived types included in the result

I cover additional types of inheritance that the EDM supports later in this chapter.

Thanks to the Designer’s copy-and-paste functionality, you can easily copy the ContactPersonalInfo properties into the Customer entity. Once you have done that, all that’s left is to map the Customer entity’s new properties back to the appropriate table:

Figure 12-10. Mapping an entity to additional tables

Now you can test the revised entity. In the following exercise, you’ll query the new entity, modify the returned object, create a new entity, and then save your changes. These actions will allow you to see how the Entity Framework handles an update and an insert involving multiple tables.

When the process stops at the breakpoint, debug the firstCust variable and you can see in the QuickWatch window that the new properties of Customer are populated, as shown in Figure 12-11.

Figure 12-11. Inspecting the queried Customer in one of the QuickWatch windows

A quick check in SQL Profiler shows that when querying for the first customer, an inner join was used to include the values from the ContactPersonalInfo table.

The SQL Profiler screenshot in Figure 12-12 shows the commands that are executed when editing a Customer and when adding a new Customer. The first two commands update the ModifiedDate field in Contact and the BirthDate field in ContactPersonalInfo for the first Customer that was queried and edited. The newly added Customer results in the creation of a Contact, a ContactPersonalInfo record, and finally, a new row in the Customers table.

Figure 12-12. A screenshot from SQL Profiler showing the commands that are executed when editing a Customer and when adding a new Customer

The first insertion occurs because of the inheritance you created between Customer and Contact, but the insertion to the ContactPersonalInfo table occurs thanks to the entity splitting you just defined in the model. The Entity Framework is able to work out this customization in the model and translate it into the correct commands in the database without the developer having to worry about modification operations or about the fact that a number of tables are involved in the query.

You must remove from the entity’s scalar properties whatever property you will be using for a conditional mapping:

Figure 12-14. Adding a conditional mapping

Figure 12-15. Adding a conditional mapping to the Activity entry indicating that only rows whose Category value is equal to Water should be returned when querying against this entity

The Is Null/Not Null conditions

If you wanted the condition to test for null values, you can change the operator by using the drop-down and selecting Is. When you set the operator to Is, Value/Property becomes a drop-down with the options Null and Not Null, as shown in Figure 12-16.

Figure 12-16. Changing the condition operator to Is, which turns Value/Property into a drop-down list with the options Not Null and Null

You’ll see with the following exercise that the condition not only filters data coming from the database, but also impacts data going into the database.

When you hit the breakpoint, look at the activities variable in the QuickWatch window. You will see that only activities in the Water category were retrieved.

The insert is even more interesting. Although the only property you set in code was the ActivityName, look at the T-SQL that was generated and you will see that Water was inserted into the Category field:

exec sp_executesql N'insert [dbo].[Activities]([Activity],
                            [imagepath], [Category])
values (@0, null, @1)
select [ActivityID]
from [dbo].[Activities]
where @@ROWCOUNT > 0 and [ActivityID] = scope_identity()',
N'@0 nchar(50),@1 nchar(10)',@0=N'WindSurfing      ',@1=N'Water     '

The condition was automatically used in the insert. The condition that all Activity entities should have a category of “Water” also means that any newly created Activity entities will also have a category of “Water”.

Removing the conditional mapping from Activity and re-creating the Category property

You may not want to have this conditional mapping in place going forward, so feel free to remove it. You’ll need to add the Category property back into the Activity entity and map it to the Category field in the Activities table.

1. Click the When Category mapping in the Mapping Details window.

2. Select <Delete> from the drop-down list.

3. Right-click the Activity entity in the Designer, and choose Add and then Scalar Property from the context menu.

4. Rename the property to Category.

5. Return to the Mapping Details window and map the Category field of the Activities table to the Category property, as shown in Figure 12-17.

Figure 12-17. Mapping the Category field of the Activities table to the Category property

The BreakAway Lodging entity has a Boolean property called Resort. Let’s use this property to define Resort as a new type of lodging:

Now that you have the new type defined, how will the Entity Framework decide which Lodging records go into the Lodging entity and which go into the Resort entity? The answer is conditional mapping.

First, we’ll use conditional mapping to filter Lodging records into the base or derived type:

Next, we’ll move resort-specific properties to the Resort entity type:

When you’re done, the Lodging and Resort types should look as they do in Figure 12-19.

Figure 12-19. A conditional mapping used to determine which rows from the Lodging table belong in Lodging or its derived entity, Resort

If you try to run code against Lodging at this point, you will encounter a problem. The LuxuryResort field is a Boolean field. In the database, it is non-nullable and has a default value of 0. The EDM Wizard does not bring the default value over to the model’s Store Schema Definition Layer (SSDL). This creates a problem for the Lodging entity. The Lodging entity maps to the Lodging table but does not map the LuxuryResort or ResortChainOwner column because we removed the properties from the Lodging entity. Only the Resort entity maps those fields. Because Lodging does not map those fields, the model will throw a runtime exception telling you that Lodging doesn’t know how to deal with LuxuryResort because it is non-nullable and has no default value. Therefore, it wants to populate it. But because the properties don’t exist in Lodging, the field is not mapped, and therefore the Lodging entity is unable to modify the value.

The only way to correct this is to add the StoreGeneratedPattern attribute manually into the SSDL to let the Entity Framework know that the database will take care of this value. This is especially important if you are creating new Lodging entities and saving them back to the database.

<EntityType Name="Lodging">
  <Key>
    <PropertyRef Name="LodgingID" />
  </Key>
  <Property Name="LodgingID" Type="int" Nullable="false"
            StoreGeneratedPattern="Identity" />
  <Property Name="LodgingName" Type="nchar" Nullable="false"
            MaxLength="50" />
  <Property Name="ContactID" Type="int" Nullable="false" />
  <Property Name="LocationID" Type="int" />
  <Property Name="Resort" Type="bit" Nullable="false" />
  <Property Name="ResortChainOwner" Type="nchar" MaxLength="30" />
  <Property Name="LuxuryResort" Type="bit" Nullable="false" 
            StoreGeneratedPattern="Computed"/>
</EntityType>

The following method will help you see the effect of the TPH mapping. You can query for all lodgings, including any derived types, or for a specific derived type. It’s a little trickier to query for a subset that is not a derived type.

The following queries are executed in unique contexts so that entities that are a result of one query do not merge with entities of another query. In this way, you can more easily see the full impact of each of the various queries:

When you see the output of the console window, you may be surprised that the second query, which you may have expected to return only nonresort lodgings, returned all of the lodgings, regardless of the Resort filter:

All Lodgings Results: 101
NonResort Type Only Results: 101
Resort Type Only Results: 10

Why is this?

Even though you put a condition on Lodging that states Resort=0 (false), Lodging is a base type. No matter what, Lodging will return itself and all types that derive from it. With a simple query it is not easy to say “give me the base type but none of its derived types.” So, even though the condition is there, you’ll continue to receive all of the Lodgings, even with Resort=1.

If you want an easy way to retrieve nonresort lodgings, you can create a second derived type that inherits from Lodging to retrieve all of the Lodging entities that are not resorts. In this case, the actual Lodging entity would become an abstract type because it will never be instantiated. The Lodging entity itself cannot be instantiated and will never return Lodging entities. Instead, the Lodgings EntitySet will return only those entities that come from its derived types: Resort and NonResort.

Although you performed this task when creating the NonCustomer entity, the following walkthrough will act as a reminder to show you how to turn Lodging into an abstract type and then let you see how the abstract and derived types behave in code:

You just saw a demonstration of how TPH inheritance works. If your business rules define that you would never want to get the entire set of types (e.g., all of the lodgings at once), it makes sense to have the abstract class in the model and to use the derived types to interact with the objects. If your business rules define that in many cases you will want to work with all lodgings, regardless of type, using the base type without defining it as an abstract class may be preferable.

Complex types are one of the mapping types that the Designer does not support, but you can still create them manually. As mentioned at the start of this chapter, “not supported by the Designer” can mean different things. In this case, when a complex type is defined in the model, you will not be able to open the model in the Designer. When you try to open it in the Designer, you will get the Designer’s “Safe Mode” display that says the Designer is unable to display the file, but provides a link to open the model in the XML Editor.

This will be highly inconvenient if you are still in the process of designing your model, but otherwise it should not be a showstopper if you find that you will get a lot of benefit from using complex types.

You can create the new complex type in the XML Editor by copying the properties from the entity that originally contains them and pasting them into a ComplexType element. ComplexType elements are siblings of EntityType elements.

As an example, you can create an AddressDetail type that encapsulates the specific properties of the Address entity that are part of the mailing address, leaving the AddressType and modified date as scalar properties of Address.

The new complex type would look like Example 12-8.

<ComplexType Name="AddressDetail">
  <Property Name="Street1" Type="String" MaxLength="50"
            FixedLength="true" />
  <Property Name="Street2" Type="String" MaxLength="50" 
            FixedLength="true" />
  <Property Name="City" Type="String" MaxLength="50" 
            FixedLength="true" />
  <Property Name="StateProvince" Type="String" MaxLength="50" 
            FixedLength="true" />
  <Property Name="CountryRegion" Type="String" MaxLength="50" 
            FixedLength="true" />
  <Property Name="PostalCode" Type="String" MaxLength="20" 
            FixedLength="true" />
</ComplexType>

As shown in Figure 12-22, the ComplexType element is positioned in the CSDL section as a sibling of the EntityTypes. It is not critical where it is placed relative to other entities.

Figure 12-22. The ComplexType element positioned as a sibling of the EntityTypes

In the Address EntityType, you can now replace those properties with a single property to represent the AddressDetails, as shown in Example 12-9. Note the new Detail property in the address and entities.

<EntityType Name="Address">
  <Key>
    <PropertyRef Name="addressID" />
  </Key>
  <Property Name="addressID" Type="Int32" Nullable="false" />
  <Property Name="Detail" Type="Self.AddressDetail" Nullable="false" />
  <Property Name="ModifiedDate" Type="DateTime" Nullable="false" />
  <NavigationProperty Name="Contact"
                      Relationship="BAModel.FK_Address_Contact" 
                      FromRole="Address" ToRole="Contact" />
</EntityType>

The required change to the mappings is not as complicated as you might think. All you need to do is wrap those properties inside a ComplexProperty tag, as shown in Example 12-10. Note that the name of the ComplexProperty element, Detail, matches the name used for the property in the entities, and that the TypeName attribute points directly to the complex types.

yyy<EntitySetMapping Name="Address">
 <EntityTypeMapping TypeName="IsTypeOf(BAModel.Address)">
  <MappingFragment StoreEntitySet="Address">
   <ScalarProperty Name="addressID" ColumnName="addressID" />
   <ComplexProperty Name="Detail"
                    TypeName="BAModel.AddressDetail">
     <ScalarProperty Name="Street1" ColumnName="Street1" />
     <ScalarProperty Name="Street2" ColumnName="Street2" />
     <ScalarProperty Name="City" ColumnName="City" />
     <ScalarProperty Name="StateProvince" ColumnName="StateProvince" />
     <ScalarProperty Name="CountryRegion" ColumnName="CountryRegion" />
     <ScalarProperty Name="PostalCode" ColumnName="PostalCode" />
   </ComplexProperty>
   <ScalarProperty Name="AddressType" ColumnName="AddressType" />
   <ScalarProperty Name="ModifiedDate" ColumnName="ModifiedDate" />
  </MappingFragment>
 </EntityTypeMapping>
</EntitySetMapping>

If you are using AddressDetail inside other entities, you will need to map the properties in EntitySetMapping for that entity.

Rebuild the model project so that the projects using it see the changes.

Looking at the generated class for AddressDetail you will see that it is not an EntityObject, but rather a ComplexObject:

VB
Partial Public Class AddressDetail
  Inherits Global.System.Data.Objects.DataClasses.ComplexObject

C#
public partial class AddressDetail : 
 global::System.Data.Objects.DataClasses.ComplexObject

Although you can instantiate and use these types directly in code, they do not have EntityKeys, cannot be queried for directly, and cannot be persisted to the database.

ComplexObject does allow the properties of the ComplexType to be change-tracked along with the other properties of its parent entity, though. You can look further at the generated class and even drill into the System.Data.Objects.DataClasses.ComplexObject class in Visual Studio’s Object Browser or in another tool such as Reflector.

The method in Example 12-11 shows the ComplexType in action.

VB
Private Sub ComplexType()
  Using context As New BreakAwayEntities
    Dim contact = (From c In context.Contacts.Include("Addresses") _
                   Take 1).FirstOrDefault
    Dim addDetail as AddressDetail = contact.Addresses(0).Detail
    Console.WriteLine("Street: {0}, City: {1}, State: {2}", _
                      addDetail.Street1, addDetail.City, _
                      addDetail.StateProvince)
    Dim newAD = New AddressDetail
    With newAD
      .Street1 = "1 Rue Cardinale"
      .City = "Montreal"
      .StateProvince = "Quebec"
    End With
    contact.Addresses(0).Detail = newAD
    context.SaveChanges()
  End Using
End Sub

C#
private void ComplexType()
{
  using (var context = new BreakAwayEntities())
  {
    var contact = (from c in context.Contacts.Include("Addresses")
                select c).Take(1).FirstOrDefault();
    AddressDetail addDetail = contact.Addresses[0].Detail;
    Console.WriteLine("Street: {0}, City: {1}, State: {2}",
                      addDetail.Street1, addDetail.City, addDetail.StateProvince);
    var newAD = new AddressDetail();
    newAD.Street1 = "1 Rue Cardinale";
    newAD.City = "Montreal";
    newAD.StateProvince = "Quebec";
    contact.Addresses(0).Detail = newAD;
    context.SaveChanges();
  }
}

This method first queries the model for a single Contact entity, along with its addresses.

It then extracts the AddressDetail from the first address and displays some of its properties, demonstrating that you can create an instance of the complex type. Next, it instantiates a new AddressDetail, and sets that instance as the Detail property of the first address. Finally, SaveChanges is called, which updates the address information for the contact.

Here is the T-SQL that was executed on the server. You can see that the change tracking does take into account the property values of the complex type:

exec sp_executesql N'update [dbo].[Address]
set [Street1] = @0, [Street2] = null, [City] = @1, [StateProvince] = @2,
    [CountryRegion] = null, [PostalCode] = null
where ([addressID] = @3)',
N'@0 nchar(50),@1 nchar(50),@2 nchar(50),@3 int',@0=N'1 Rue Cardinale',
  @1=N'Montreal',@2=N'Quebec',@3=2513

The complex type may not behave the way you would expect it to in data binding. Therefore, the next few pages will take a look at a number of data-binding scenarios.

ASP.NET EntityDataSource

When you use complex types with the EntityDataSource, the EntityDataSource “flattens” the properties within the complex type to make them easily accessible. When configuring the EntityDataSource, you will see the type, but not the properties, as you can see in Figure 12-23. However, when binding controls to the data source, the properties of the complex type appear as though they were simply properties of the parent type. You can see this in the screenshot in Figure 12-24.

Figure 12-23. The complex type surfaced by the EntityDataSource

Figure 12-24. The complex type properties automatically flattened

This flattening of the properties is a feature of the EntityDataSource, though it will occur only under specific conditions. For details, see the blog post “EntityDataSource: To wrap or not to wrap” by Diego Vega, EntityDataSource program manager at Microsoft (http://blogs.msdn.com/diego/archive/2008/05/13/entitydatasource-to-wrap-or-not-to-wrap.aspx/).

When you attempt to perform data binding against query results where complex types are involved and DataSource controls are not, you won’t have such easy access to the properties.

For example, the following code in an ASP.NET page will fail, with a message saying that Address does not contain a property with the name Detail.City:

VB
Dim addresses = context.Addresses.ToList
With DropDownList1
  .DataTextField = "Detail.City"
  .DataValueField = "addressID"
  .DataSource = addresses
  .DataBind()
End With

C#
var addresses = context.Addresses.ToList();
DropDownList1.DataTextField = "Detail.City";
DropDownList1.DataValueField = "addressID";
DropDownList1.DataSource = addresses;
DropDownList1.DataBind();

Attempting a similar binding to a ComboBox in a Windows form will have a different effect. In the following code, the addressID will be displayed in the drop-down list, rather than the ComplexType property that is used for DisplayMember:

VB
Dim addresses = context.Addresses
With ComboBox1
  .DataSource = addresses
  .DisplayMember = "Detail.City"
  .ValueMember = "addressID"
End With

C#
var addresses = context.Addresses;
ComboBox1.DataSource = addresses;
ComboBox1.DisplayMember = "Detail.City";
ComboBox1.ValueMember = "addressID";

Yet, if you were to debug into the results of the query and request the properties from the complex type, you would see that they are definitely available, just not for these data-binding scenarios.

In a Windows form, if you bound the results of a query programmatically, such as in the following code:

VB
Using context = New BAGA.BreakAwayModel.BreakAwayEntities
  Dim addresses = From a In context.Addresses Select a
  Me.DataGridView1.DataSource = addresses
End Using

C#
using (var context = new BAGA.BreakAwayModel.BreakAwayEntities())
{
  var addresses =
      from a in context.Addresses
      select a;
  this.DataGridView1.DataSource = addresses;
}

the Detail property would be represented incorrectly as a single column.

You’ll get the same effect even if you create a Windows Forms DataSource and bind to that.

Even if you explicitly bind properties to the columns in this way:

VB
DataGridView1.Columns(1).DataPropertyName = "Detail.Street1"

C#
DataGridView1.Columns[1].DataPropertyName = "Detail.Street1";

the binding will fail, with the columns that result being empty.

So, how can you get at these properties in these scenarios?

VB
Dim uniqueCities = From a In context.Addresses _
                   Select City = a.Detail.City Distinct
With DropDownList1
  .DataSource = uniqueCities
  .DataBind()
End With

C#
var uniqueCities = 
    (from a in context.Addresses
     select City == a.Detail.City)
    .Distinct();
DropDownList1.DataSource = uniqueCities;
DropDownList1.DataBind();

context.Addresses

<asp:ListView runat="server" ID="ListView1">
  <LayoutTemplate>
    <table runat="server" id="table1" >
      <tr runat="server" id="itemPlaceholder" ></tr>
    </table>
  </LayoutTemplate>
  <ItemTemplate>
    <tr runat="server">
      <td id="Td1" runat="server">
        <%-- Data-bound content. --%>
        <asp:Label ID="NameLabel" runat="server" 
          Text='<%#Eval("Detail.Street1") %>' />
      </td>
      <td id="Td2" runat="server">
        <%-- Data-bound content. --%>
        <asp:Label ID="Label1" runat="server" 
          Text='<%#Eval("Detail.City") %>' />
      </td>
    </tr>
  </ItemTemplate>
</asp:ListView>

Like the EntityDataSource, data sources in Windows Forms let you work with entities and their properties that are complex types fairly easily.

Figure 12-25 shows an Object data source created from the revised Address entity.

Figure 12-25. Windows Forms data source reading complex type properties such as the Detail property of Address

You can use the complex type in a Windows form, which is displayed and updated along with the rest of the entity. You can see in the simple form shown in Figure 12-26 that the complex type properties blend in as though they were scalar properties of Address.

Figure 12-26. The AddressDetails complex type being used with a data source in a Windows form

The code for this form doesn’t make any special accommodation for the Detail property (see Example 12-13).

VB
Public Class Form1
  Private _context As BAEntities
 
  Private Sub Form1_Load(ByVal sender As System.Object, _
   ByVal e As System.EventArgs) Handles MyBase.Load
    _context = New BAEntities
    Dim query = From a In _context.Addresses Select a
    AddressBindingSource.DataSource = query
  End Sub

  Private Sub AddressBindingNavigatorSaveItem_Click _
   (ByVal sender As System.Object, ByVal e As System.EventArgs) _
   Handles AddressBindingNavigatorSaveItem.Click
    _context.SaveChanges()
  End Sub

End Class

C#
public partial class Form1 : Form
{
  BAEntities _context;
  public Form1()
  {
    InitializeComponent();
  }

  private void Form1_Load(object sender, EventArgs e)
  {
  _context = new BAEntities();
  var query = from a in _context.Addresses select a;
  addressBindingSource.DataSource = query;
  }

  private void addressBindingNavigatorSaveItem_Click
   (object sender, EventArgs e)
  {
    _context.SaveChanges();
  }
}

If you have followed along and modified the model, you may want to undo these changes so that you’ll be able to open the model while working through more sample code in this book:

You should now be able to open the model in the Designer again.

You may also need to remove or comment out any code that relates to the AddressDetail complex type. The compiler will point them out in the Error List window for you.

Because of the complexity of the BreakAway model, if you would like to test the QueryView, it would be best to get your first look with a simpler model.

In this exercise, you will be adding a condition to the Contacts EntitySet to make sure all queries will return only customers who were added to the database since January 1, 2007:

In the main module of this project, add the following simple code to verify the QueryView:

VB
Using context = New BAModel.BAEntities
      Dim contacts = context.Contacts.ToList
End Using

C#
using (var context = new BAModel.BAEntities())
{
  var contacts = context.Contacts.ToList();
}

Set a breakpoint at the end of the Using clause and run the test.

When the debugger stops at the breakpoint, check out the contacts variable in the QuickWatch window. If you drill into the different contacts in the list, you will see only contacts whose AddDate is 1/1/2007 or later.

The order of the projected columns in the preceding example is not random. Since you no longer have any property mappings, the Entity Framework relies on the QueryView to provide the values in the order in which the entity expects.

The following expression is different from those that you have written against the conceptual layer:

<QueryView>
SELECT VALUE QVModel.Contact(c.ContactID,c.FirstName,c.LastName,c.Title
                             c.AddDate,c.ModifiedDate,c.TimeStamp)
FROM QVModelStoreContainer.Contact as c
</QueryView>

Using VALUE designates that you will be returning an object, as you have seen before. Following that is a type constructor, similar to what you would use in .NET code.

In fact, you can see this in action if you return to the XML and modify the query, perhaps by removing one of the fields or changing the order. Removing a field will throw an obvious mapping exception at runtime that reads as follows:

The query view specified for the EntitySet 'Contacts' is not valid.
The query parser threw the following error : The type constructor
argument 'ModifiedDate' is missing., near type 'BAModel.Contact'
constructor, line 1, column 29.

Remember that the returned types are read-only. If you modify them and call SaveChanges, no commands will be created to update the database. However, if you explicitly map stored procedures to the entity using function mapping, any changes will be persisted to the database when SaveChanges is called.

The database has stored procedures called InsertContact, UpdateContact, and DeleteContact. If you want to try this out, update the model, adding these three stored procedures, and then create the function mappings as you did in Chapter 6. You can modify the code in the main module to test the change tracking and updates.

One of the rules noted earlier is that if you use a QueryView on an entity that is part of an inheritance hierarchy, you need to have QueryViews for all other entities in that hierarchy.

Let’s add some inheritance into this sample model and see how to set up the QueryViews for base and derived entities:

There are a few things to note regarding this new QueryView.

First, the QueryView’s TypeName attribute is specified. This is a requirement. The rule is that the first QueryView must not have a TypeName attribute. A runtime exception will specifically point this out if you break the rule. But all other QueryViews within an EntitySetMapping must have the TypeName attribute. It is the same attribute and value that are used in the regular mapping.

The next point to note is that the query is returning all of the values for the customer record using a JOIN query. Standard mappings need to map only the properties that are in the derived type. But with a QueryView, you need to return properties from the base type. Except for the type constructor, this JOIN query is similar to the JOIN queries you saw in Chapter 4.

VB
TypeOf(Of Customer) 

C#
context.Contacts.TypeOf<Customert>

<QueryView>
  SELECT VALUE
    CASE
    WHEN (cu.ContactID IS NULL) THEN
      QVModel.Contact(c.ContactID,c.FirstName,c.LastName,
      c.Title,c.AddDate,c.ModifiedDate,c.TimeStamp
    ELSE
      QVModel.Customer(c.ContactID,c.FirstName,c.LastName,
      c.Title,c.AddDate,c.ModifiedDate,c.TimeStamp,
      cu.CustomerTypeID,cu.InitialDate,cu.PrimaryDesintation,
      cu.SecondaryDestination,cu.PrimaryActivity,
      cu.SecondaryActivity,cu.Notes
    END
  FROM QVModelStoreContainer.Contact as c
  LEFT OUTER JOIN QVModelStoreContainer.Customers as cu
  ON cu.ContactID=c.ContactID
  WHERE c.AddDate>= DATETIME'2007-01-1 00:00'
</QueryView>

Now that you have modified the QueryView to account for the inheritance hierarchy, let’s test it out with some code:

Figure 12-27. The QueryView returning properly typed entities

In addition to the function mapping you used earlier in the book, you can map stored procedures manually using a number of other methods. This includes mapping those that are already in your database and those that you can create directly in the model. We’ll cover these in the next chapter.

Multiple Entity Sets per Type (MEST) allows you to contain a single entity in different types, which could allow you to have different views of the same type without using an inheritance model. However, MEST gets tricky pretty quickly when you start to introduce entities that have relationships with other entities. Alex James from the Entity Framework team has a great blog post about MEST and its gotchas in his May 16, 2008, post, “MEST—What is it and how does it work?” (http://blogs.msdn.com/alexj/archive/2008/05/16/mest-what-is-it-and-how-does-it-work.aspx/).

You can find a great example of self-referencing associations in the Northwind database, where employees and their supervisors (who are also employees) are contained in the same table. A field called ReportsTo points back to other employees in the table. When you use the EDM Wizard to create a model from AdventureWorksLT, you will see that an association has been created that links the SupervisorID back to the EmployeeID in the same table. Figure 12-28 shows this association.

Figure 12-28. An example of a self-referencing association in the Employee entity, which is created from the Employees table in the Northwind database