Export (0) Print
Expand All

ASP.NET Dynamic Data Guidelines

Updated: August 2008

ASP.NET Dynamic Data provides a range of customization that lets you adapt a Web site to your needs. This customization can be done at the presentation layer or the data layer. Often, Dynamic Data provides more than one option for implementing a customization. This topic contains guidelines and suggestions that can help you select the best options for working with the data model and for customizing the behavior and appearance of pages that are displayed by Dynamic Data.

Dynamic Data supports the LINQ to SQL and the ADO.NET Entity Framework data models. These models target different scenarios. The following sections describe the differences in using these models.

LINQ to SQL

LINQ to SQL targets Microsoft SQL Server databases. It enables you to have a strongly-typed view of an existing database schema. LINQ to SQL supports a direct, one-to-one mapping of an existing database schema to .NET Framework classes. A single table is mapped to a single class, and foreign keys can be exposed as strongly-typed relationships.

Using LINQ to SQL classes, you can build LINQ queries for tables, views, and table-valued functions, and return results as strongly typed objects. You can also call stored procedures by using strongly typed methods that return strongly typed results. A key design principle of LINQ to SQL is that it is optimized for common cases. 

ADO.NET Entity Framework

The ADO.NET Entity Framework targets enterprise scenarios. In these scenarios, database schemas are typically optimized by a database administrator for performance, consistency, and partitioning. Therefore, they might not be ideally designed for exposing an object-oriented application model. Moreover, a schema might change over time based on usage data and usage patterns.

The Entity Framework exposes an application-oriented data model that is loosely coupled to the database, and that might differ significantly from the actual existing database schema. For example, you can map a single class (or entity) to multiple tables or you can map multiple classes to the same table. You can map an inheritance hierarchy to a single table (as in LINQ to SQL) or to multiple tables.

This flexible mapping is specified declaratively. It enables the schema of the database to evolve without requiring the application to be recompiled for each schema change.

The Entity Framework includes LINQ to Entities, which exposes many of the same features as LINQ to SQL, and which lets you use LINQ queries to work with the data model.

For more information, see Introducing LINQ to Relational Data.

When you use the Entity Framework to create a data model, you must take into account the following differences from using LINQ to SQL:

  • 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.

  • The Entity Data Model (EDM) supports a set of related information by using the ComplexType class, but ASP.NET Dynamic Data does not support this type.

  • When you use the EDM, 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 primary keys that are generated automatically. The EDM does not have an equivalent attribute, so Dynamic Data cannot detect automatically generated keys. As a result, with LINQ to SQL, automatically generated primary keys are not displayed. However, the keys are displayed when you use the EDM.

  • You can hide the primary key as you do any other column by using the Scaffold attribute and setting its value to false. Because automatically generated keys are not recognized, the default Insert page templates do not work with EDM 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.

  • If you create a page by using a ListView or other control that uses the EDM, you must explicitly set the ContextType property of the data source, which you do in EntityDataSource markup, as shown in the following example:

    protected void Page_Init(object sender, EventArgs e) {
        EntityDataSource1.ContextType = 
            typeof(AWLT08Model.AWLT08Entities);
        DynamicDataManager1.RegisterControl(GridView1);
    }
    

    Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
        EntityDataSource1.ContextType = _
            GetType(AWLT08Model.AWLT08Entities)
        DynamicDataManager1.RegisterControl(GridView1)
    End Sub
    
  • 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.

  • 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, imagine that 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.

ASP.NET Dynamic Data includes field templates that render the UI for displaying and editing data fields. Typically, for each intrinsic data type, there is one field template for displaying data and another one for modifying or inserting data for that data type. You can customize how data is rendered for display and editing by changing the default field templates or by creating new custom field templates. The following sections describe the customization options.

Customizing Appearance and Behavior of Data Fields in the Data-Model Layer

You can customize how data is rendered for display and editing at the data-model layer. Use this approach when you want to customize appearance and behavior globally for a Web site. You have the following options:

Customizing Appearance and Behavior of Data Fields in the Presentation Layer

You can customize how data is rendered for display and editing in individual page templates. Use this approach when you want to customize the UI for a specific view (page template) or table. You have the following options:

  • Customizing the markup for an existing page template. Use this option if you want to customize the UI for a specific template globally in a Web site.

  • Customizing the UI for individual data fields in a custom page, which is a page that you have created that lists each field to display. (This does not refer to a custom page template in the DynamicData\CustomPages directory.) You customize the data fields by setting the UIHint property of a Dynamic Data control such as the DynamicControl control or the DynamicField field. The UIHint property of these controls specifies what field template to use to render the data for that field. For more information, seeHow to: Customize Data Field Appearance and Behavior in a Dynamic Data Control.

ASP.NET Dynamic Data includes classes that enable you to add dynamic behavior to existing data-bound controls such as the GridView, DetailsView, FormView, and ListView controls. These classes are the DynamicDataManager, DynamicControl, and DynamicField classes. You use these controls in place of standard bound fields or template fields in data-bound controls. By using these controls, you can delegate the rendering of data fields to Dynamic Data. You have the following options to enable the dynamic behavior of data-bound controls:

ASP.NET Dynamic Data enables you to customize how data is validated. The following sections describe validation options.

Performing Data Field Validation in the Data Layer

You can perform data-field validation in the data model. Use this approach when you want to apply data-field validation globally to a Web site. You have the following options to perform global data-field validation:

Performing Data Field Validation in the Presentation Layer

You can perform data-field validation in the presentation layer. Use this approach when you want to apply data-field validation only in specific pages. You perform this type of data-field validation by adding ASP.NET validation controls to a field template. You can add validation controls to a field template that already has validation controls, or you can create a custom field template and add the validation controls that you want.

You can control the errors that are displayed when validation fails by applying System.ComponentModel.DataAnnotations attributes to a partial class that extends the data model for the entity. You have the following options to work with validation error messages:

  • Using the default error messages that are associated with built-in validation controls. These messages are localized based on the locale of the .NET Framework that is used to build the Dynamic Data application.

  • Deriving a custom class from ValidationAttribute and formatting the error message by using the ErrorMessage property.

  • Providing an error message resource file that can be localized by using the ErrorMessageResourceName property. You can then specify the error message this is contained in the resource file by using the ErrorMessageResourceType property.

Dynamic Data scaffolding displays pages that are based on the data model by using page templates. These page templates enable you to perform create, read, update, and delete (CRUD) operations.

By default, scaffolding is turned off. Enabling scaffolding can pose a security risk because it can expose the whole data model for display and modification. To reduce this risk, you can use the following approaches to limit access to data:

Controlling Scaffolding for Individual Data Fields

You can control scaffolding for individual data fields by using the ScaffoldColumnAttribute attribute in a partial class that extends the data model. By default, most data fields in the data model have the Scaffold property set to true. The exceptions are fields such as computed fields or binary fields. You can set the Scaffold property of the ScaffoldColumnAttribute attribute to true to expose a data field that is not automatically exposed, and you can set the attribute to false to hide a field from the scaffolding mechanism. Hiding a particular field is useful when you do not want to expose fields that contain sensitive information such as passwords or credit card numbers.

For more information, see ASP.NET Dynamic Data Scaffolding and Page Templates Overview.

Date

History

Reason

August 2008

Added ADO.NET Entity Framework differences and added new content to existing sections.

Information enhancement.

July 2008

Added topic.

SP1 feature change.

Community Additions

ADD
Show:
© 2014 Microsoft