Entity Framework 4.1 4: complex types

Original article name: Entity Framework 4.1: complex types (4)

Address: http://vincentlauzon.wordpress.com/2011/04/13/entity-framework-4-1-complex-types-4/

We can see the English tutorial recommended for Entity Framework 4.1. To help you look more convenient, we can translate it briefly. This is a series of 8 articles, and this is 4th articles.

1. One of Entity Framework 4.1: Basic
2. Entity Framework 4.1 II: overwrite the default conventions
3. Entity Framework 4.1 3: greedy loading and delayed Loading
4. Entity Framework 4.1 4: complex types
5. Entity Framework 4.1-5: Multi-to-many relationships
6. Entity Framework 4.1: Optimistic Concurrency
7. Entity Framework 4.1 7: Inheritance
8. Entity Framework 4.1: bypassing EF query ing

This articleArticleThe complex types will be discussed.

By default, ef4.1 maps classes to tables, which is a convention. However, sometimes, we need a model with a finer granularity than a table.

The address is a typical example. Let's look at the customer class under the example.

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 attributes to be mapped to the records in the address table. Instead, we want ef4.1 to be mapped to a table to expand the addresses. How can we do this? You can use complex types.

As we have seen earlier, we always use labels or model builders to overwrite the default conventions. As I mentioned, when we enrich the business model, such as mandatory items, we recommend that you use attributes. Now I want to map the complex attributes in the class to the fields in the table, so we use the model builder instead of labels.

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 the client-ID as the Automatically increasing ID column. Then, the specified address is of a complex type. If you like, you can add the [complextype] label to the class. Then, use the lambda expression to map each sub-attribute to the column, which will generate the following table.

Now you can use the model.

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=NewMydomaincontext ())
{
VaR clients=From WInContext2.clients
WhereW. 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 );
}
}

For complex types, the most important thing to note is empty management. Even if all attributes of a complex type are empty, you cannot set the entire complex type object to null. For example, in this case, even if the street name and street number are not required, a residential address cannot be null. You need to create an address object with all attributes null. Similarly, when you obtain an object, ef4.1 creates a complex object even if all attributes are null.