Recently I have been working with Entity Framework V6 using the Code First Implementation. Code first has been the increasing in popularity, where you define your classes first, and then Entity Framework generates a database with tables modeled after your classes. Code first continues to grow in popularity, and appears to be the primary, or only, technique moving forward into Version 7 of entity framework.
In order for entity framework to create a database accurately it depends on the developer providing attributes to direct the generation of a database table correctly. There are other techniques to use as well, such as defining properties as virtual. We’ll get into that at a later time.
.
Here is a POCO, “Plain Old CLR Objects”, model for this discussion.
public class Color
{
public int ColorId { set; get; }
public string Name { get; set; }
}
By default, ColorId will be the primary key for a new table called Colors when it is generated for my database. You may use a property called ID or ColorID and EF will know that represents a unique, sequential, Identity column as a record identifier. If you want to be sure EF knows what it is, you can decorate the ColorId property with the attribute [Key].
[Key]
public int ColorId { set; get; }
When it comes to the data type string, used as the .Net type for the property Name, EF is much more uncertain. It knows it can be any number of SQL Server character types, and the length is unlimited. Defined in your class like this, it will generate a column in your database table of NVARCHAR(MAX). Technically, you could create all your string variables as NVARCHAR(MAX). By default, if the contents are small enough they are stored in the page with the record. If they are too big, then they are spread across multiple pages as a linked list.
A database with unlimited size is not the best design. So, you provide hints to entity framework by decorating your string data types, establishing length and limiting the character definition from NCHAR to CHAR, etc. To provide information necessary for EF to correctly generate the correct string data type in SQL Server you provide additional guidance through Decorations. For our Name property, it would now look as follows.
[StringLength(32, MinimumLength = 1)]
[Required]
public string Name { get; set; }
Personally, I like it when EF uses naming convention to determine how to behave. That keeps the POCO classes clean, without passing along Decorations to make EF work. On the other side of that argument, those additional Decorations are definitive not only of your database, but also of you POCO class, and communicate to any consumer behaviors you expect to implement.
Those decoration definitions are found in System.ComponentModel.DataAnnotations, so they are not even EF specific. EF simply uses them when generating a database, and SQL code.
Tomorrow we’ll look at some different techniques provided in EF. Do you like this implementation? Is it too intrusive on your POCO classes? Share your comments here if you like.
Cheers,
Ben