I saw complex types in the March CTP of Entity Framework and tried to implement them but found out the hard way that the functionality wasn’t fully implemented. Here’s the forum thread from that time.

So Complex Types were the first thing I wanted to try out on Danny’s list of what’s new in Beta 2. Complex types can only be used as properties of other entities. They have no keys and can only have a one to one relationship with the main entity.

Here is his description:

Complex types “Complex types” is the Entity Framework name for value properties which have more intricate structure than scalars.  The canonical example is an Address type which contains several parts (street, city, state, etc.)  Complex types are somewhat like entities except that they do not have any identity of their own (they are value types).  This means that a complex type instance is always a part of some other enclosing entity—it can’t stand on its own, it doesn’t have relationships, etc.  In this release, the mapping scenarios for complex types are significantly limited: inheritance is not supported, complex type properties cannot be null and they can only occur in single instances, not collections.

I am using the Adventureworks LT database, which can be found on the CodePlex site for SQL Server Product Samples.

I modified the entity for SalesOrderHeader taking the ShipDate and ShipMethod properties and putting them into their own complex type.  I had to do this manually in the XML. There’s no support for it currently in the Designer.

   <ComplexType Name=”ShipmentDetails”>
     <Property Name=”ShipMethod” Type=”String” Nullable=”false” MaxLength=”50″ />
     <Property Name=”ShipDate” Type=”DateTime” />
    </ComplexType>

Then the SalesOrderHeader needs a property to hook up to the ShipmentDetails.

     <Property Name=”Shipment” Type=”Self.ShipmentDetails” Nullable=”false” />

Next I modified the mapping so that it could find the properties in their new spot.

This mean moving the ScalarProperties for those fields into a ComplexProperty. Note that the ComplexProperty is a sibling of the other ScalarProperties inside of the MappingFragment.

The ComplexProperty Name points to the name of the property in the entity and the typename, which has a reference to the namespace of the Conceptual Layer, points to the ComplexType that I created.

The complex type does not get surfaced in the current version of the designer or in the browser. All you can see is the shipment property and it has no Type defined.

But it is well represented in the class that is generated and available in code with help from intellisense:

In the end, I thought something was wrong because all of the ShipDates and ShipMethods were the same, but it turned out that this is what the raw data looks like in the sample database. So I changed some of the data and ran it again to be sure.

Now when I have entities with a lot of properties, I can make them more organized and readable with complex types. Since the designer is only the CTP1, I’m giving them the benefit of the doubt that I’ll see the complex type in the designer eventually.

Note: The complex type came through like a champ when I returned SalesOrderHeaders from a web service.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!