Differences When Working with the ADO.NET Entity Framework to LINQ to SQL

  • [アーティクル]

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"

     ContextTypeName="AdventureWorksLT2008Model.AdventureWorksLT2008Entities"

     ConnectionString="name=AdventureWorksLT2008Entities"

     DefaultContainerName="AdventureWorksLT2008Entities"

     EntitySetName="Address" OrderBy="it.[AddressID]"

     Select="it.[AddressID], it.[AddressLine1], it.[City],

          it.[StateProvince], it.[CountryRegion], it.[PostalCode]">

 </asp:EntityDataSource>

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:

§ DataField="Address.AddressID"

§ DataField="Address1.AddressID"

§ DataField="Customer.CustomerID"

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.

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.

Comments

  • Anonymous
    October 16, 2008
    I wanted to add Dynamic Data functionality in my existing mvc app. Therefore, I downloaded the sample
  • Anonymous
    March 15, 2010
    Thanks for that.I'm a little bit disappointed to encounter such differences. I expected a little bit more from Microsoft. I would rather have something that works well in the future rather than something that doesn't work quite well now. Or at least make all the caveats known upfront in the documentation and elsewhere. I'm working on a project using Entity Framework. I would like to use Dynamic Data for the UI but currently facing problems displaying referenced columns. I just get a blank. I guess they are not being loaded. Is there a way to address this?
  • Anonymous
    March 15, 2010
    Hi Eric,Thanks for commenting.I wrote the blog over a year ago to explain the major differences between EF and L2S when using Dynamic Data. >disappointed to encounter such differences.EF and L2S are independent projects. They never had the goal of compatibility with each other.Regarding the road-map for L2S and EF: >I would like to use Dynamic Data for the UI but currently facing problems displaying referenced columns. I just get a blank. I guess they are not being loaded. Is there a way to address this?Please post a detailed question at http://forums.asp.net/1145.aspxSee Tips on getting your ASP.NET Dynamic Data questions answered quickly at http://blogs.msdn.com/davidebb/archive/2009/01/11/tips-on-getting-your-asp-net-dynamic-data-questions-answered-quickly.aspxIf you’re building a new application, we recommend that you start with the Entity Framework rather than LINQ to SQL.We continue to invest in both the Entity Framework and LINQ to SQL in .NET 4.0 and beyond. In .NET 4.0, we made a number of performance and usability enhancements to LINQ to SQL, as well as updates to the class designer and code generation. We will add new features as customer needs dictate, but we expect that the bulk of our overall investment will be in the Entity Framework, as this framework is built around the Entity Data Model (EDM).EDM represents a key strategic direction for Microsoft that spans many of our products, including SQL Server, .NET and Visual Studio.  EDM-based tools, languages and frameworks are important technologies that enable our customers and partners to increase productivity across the development life-cycle and enable better integration across applications & data sources.Thanks again,Rick Anderson, Microsoft UE