When you use the ADO.NET Entity Framework to create a data model, you must take into account the following differences from using LINQ to SQL for the data model:
1. The default Dynamic Data page templates do not support navigation and other features for many-to-many relationships. The Entity Framework lets you represent many-to-many relationships directly, without representing the join table as an entity in your data model. Dynamic Data supports many-to-many entities but not many-to-many navigation, shaping and other many-to-many features.
2. The Entity Framework can support a set of related information by using a ComplexType object, but ASP.NET Dynamic Data does not support this type.
3. When you use the Entity Framework, Dynamic Data cannot determine whether the primary key is auto generated. The LINQ to SQL data context uses the attribute value IsDbGenerated for the ColumnAttribute attribute to mark automatically generated primary keys. The Entity Framework does not have an equivalent attribute, so Dynamic Data cannot detect automatically generated primary keys. As a consequence, with LINQ to SQL, automatically generated primary keys are not displayed. However, the keys are displayed when you use the Entity Framework. You can hide the primary key as you do any other column by using the Scaffold attribute and setting the attribute value to false. Because automatically generated keys are not recognized, the default Insert page templates do not work with Entity Framework for tables that have automatic primary keys unless you create a partial class for the entity and apply the Scaffold attribute with a value of false.
4. If you create a page using a ListView or other control that uses the Entity Framework, you must explicitly set the ContextType property of the data source, which you do in EntityDataSource markup, as shown in the following example:
<asp:EntityDataSource ID=”EntityDataSource1″ runat=”server”
Select=”it.[AddressID], it.[AddressLine1], it.[City],
it.[StateProvince], it.[CountryRegion], it.[PostalCode]”>
5. If you use Visual Studio to create pages that include a ListView control, the ListView control will contain foreign key fields of the form foreign_key_entity.primary_key. (This is true for the Entity Framework only; such fields are not created if you are using LINQ to SQL.) For example, imagine that you create a custom page that contains a ListView control and a EntityDataSource control that ultimately references the SalesOrderHeader table in the AdventureWorksLT database. The designer creates the following data field references for the three foreign keys in the SalesOrderHeader entity:
Delete the markup that contains these foreign-key references.
6. If you use Visual Studio to create custom pages that include a ListView control, the ListView control will contain data fields for each foreign-key field. The fields will be empty when the custom page is rendered. The data field name will be derived from the name of the foreign-key entity. For example, if you create a custom page that contains a ListView control and a EntityDataSource control that references the SalesOrderHeader entity, the designer creates the following data field references for the three foreign keys in the SalesOrderHeader entity:
§ DataField=”Address”, which corresponds to the foreign-key field ShipToAddressID.
§ DataField=”Address1″, which corresponds to the foreign-key field BillToAddressID. The data field is named “Address1” to prevent a name collision with the data field “Address” that is created from the foreign-key field ShipToAddressID.
§ DataField=”Customer”, which corresponds to the foreign-key field CustomerID.
– Rick Anderson
ASP.NET User Education
This posting is provided “AS IS” with no warranties, and confers no rights.
– Rick Anderson
Give Your Feedback on the Documentation Help us improve the developer documentation by taking the Visual Studio and .NET Framework Content Survey. This survey will give us a better understanding of the type of applications you are developing as well as how you use Help and how we can improve it. The survey takes only 10 minutes, and we appreciate your feedback.
Give Your Feedback on the Documentation
Help us improve the developer documentation by taking the Visual Studio and .NET Framework Content Survey. This survey will give us a better understanding of the type of applications you are developing as well as how you use Help and how we can improve it. The survey takes only 10 minutes, and we appreciate your feedback.