Entity Framework 4.1: Complex Types (4)

This is part of a series of blog post about Entity Framework 4.1.  The past blog entries are:

• Basics (1)
• Override conventions (2)
• Deep Fetch vs Lazy Load (3)

In this article, I’ll cover the complex types.

By default, EF 4.1 is mapping classes to table.  That is convenient but sometimes, we would like our model to be a bit more granular than the tables.

A classical example is an address class.  Let’s say we have the following client class:

public class Client
{
    public int ClientID { get; set; }
    [Required]
    [StringLength(32, MinimumLength=2)]
    public string ClientName { get; set; }
    public Address ResidentialAddress { get; set; }
    public Address DeliveryAddress { get; set; }
}

public class Address
{
    [Required]
    public int StreetNumber { get; set; }
    [Required]
    [StringLength(32, MinimumLength=2)]
    public string StreetName { get; set; }
}

We do not want the two address properties to map to an entry in an address table.  Instead we want EF 4.1 to map the entire class to one table, flattening the address properties.  How do we go about that?  Enters complex types.

As we’ve seen previously, there’s always an attribute and a model-builder path when we want to override conventions.  As I mentioned, I recommend going with the attributes when we enrich the model with business elements (e.g. required field).  I consider complex types as a detail of mapping classes to tables, hence I won’t use attributes.  I’ll do it all the model builder way:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);

    modelBuilder.Entity<Client>().Property(x => x.ClientID)
        .HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity);
    modelBuilder.ComplexType<Address>();
    modelBuilder.Entity<Client>().Property(i => i.ResidentialAddress.StreetNumber).HasColumnName("ResStreetNumber");
    modelBuilder.Entity<Client>().Property(i => i.ResidentialAddress.StreetName).HasColumnName("ResStreetName");
    modelBuilder.Entity<Client>().Property(i => i.DeliveryAddress.StreetNumber).HasColumnName("DelStreetNumber");
    modelBuilder.Entity<Client>().Property(i => i.DeliveryAddress.StreetName).HasColumnName("DelStreetName");

}

First I specify that client-id is an identity column (auto-incremental).  Then I specify that the address class is a complex type.  You can also put [ComplexType] on top of the class if you want.  Then I do map each sub property (handing out the path of the sub property in the lambda expression) to a column name.  This generates the following table:

Now I can use the models:

    using (var context1 = new MyDomainContext())
    {
        var client = new Client
        {
            ClientName = "Joe",
            ResidentialAddress = new Address
            {
                StreetNumber = 15,
                StreetName = "Oxford"
            },
            DeliveryAddress = new Address
            {
                StreetNumber = 514,
                StreetName = "Nolif"
            }
        };
        context1.Clients.Add(client);

        context1.SaveChanges();
    }
    using (var context2 = new MyDomainContext())
    {
        var clients = from w in context2.Clients
                      where w.ClientName == "Joe"
                      select w;

        foreach (var client in clients)
        {
            Console.WriteLine("client residential StreetNumber:  " + client.ResidentialAddress.StreetNumber);
            Console.WriteLine("client residential StreetName:  " + client.ResidentialAddress.StreetName);
            Console.WriteLine("client delivery StreetNumber:  " + client.DeliveryAddress.StreetNumber);
            Console.WriteLine("client delivery StreetName:  " + client.DeliveryAddress.StreetName);
        }
    }

The big caveat with complex types is the null management.  Even if all the properties in the complex type are nullable, you can’t just hand out a null complex type.  For instance, in this case, even if street name & street number wouldn’t be required, I couldn’t have a client with a null residential address:  I would need to new an address with everything null in it.  The same way, when you retrieve an entity, EF 4.1 will always new the complex type even if everything is null in it.