Conventions in the Entity Framework 4.0 FEATURE CTP 4

Just a few days ago the new Entity Framework 4 FEATURE CTP 4 was released containing exciting updates to the “Code First” programming model. I will be writing more on the new possibilities, but at first here are some of the new Conventions within EF 4.0. … ?? … Wait! A FEW days ago??? They were released in June! Uuuh… that’s right. And that’s exactly what happens when you create a draft and never finish it. So I didn’t change my starting line to always remind me on the following: “FINISH YOUR STUFF EARLY, SON”! Back to the topic…

So what are conventions and how can we use them? Well, the good news is: conventions just work. You don’t have to do anything special to use them, but only follow a few rules in the naming of your entities and their properties. For example: books usually have an ISBN number as an identifier. You will have to tell EF that the property ISBN is the PrimaryKey for the entity Book. But if your entity was a customer who doesn’t have a natural id you could use a property like Id or CustomerId. Now, usually you still would need to tell EF that this is your PK. This is where conventions come into the game. Using its conventions, EF keeps looking for Properties in an entity with a specific naming style. If it finds one that is either named Id or is a combination of the entity name and the word Id like CustomerId it expects this to be the Identifier (PrimaryKey) for this entity. So, this can be pretty timesaving! Following you can see which new conventions can be found inside of the new Feature CTP 4:

Primary Keys:
Just name the identifier property of your entity class Id or “entity + Id” (CustomerId f.e.) and it will be considered the primary key field. This is not case sensitive.

Relationships:
This is a cool one: if you have two entities related to each other like in the following sample, these can be wired up pretty easy:

 public class EntityOne
{
    public int Id { get; set; }
    public ICollection<EntityTwo> OtherEntities { get; set; }
}

public class EntityTwo
{
    public int Id { get; set; }
    public EntityOne Parent { get; set; }
}

 One point though, this only works if there is only one navigation property on either of the two types.

Type Discovery:
This is about referenced types. Using the regular release of EF 4.0 referenced types would not be taken into account if not specified via a derived context or using the fluent API. This is not as unsual, as it might sound at first. Remeber WCF contracts referencing custom types? There also is a special attribute (KnownTypeAttribute) to tell the DataContractSerializer that some types need to be included. Anyways, just use it and it will work now. No strange TypeNotFound Exceptions.

Complex Types:
The last one for now is about complex types which represent custom types in Sql Server. You don’t have to register it explicitly, but EF will understand that a referenced type will be a complex type if no primary is defined or can be infered from the property names (see Primary Keys convention).

Although you don’t have to do anything to take advantage of this conventions I do beliefe it’s good to understand what conventions are in place and why EF 4.0 is behaving the way it does.

The next post on the EF 4.0 will be a full demo app. Until then, happy coding!

Advertisement