ASP.NET Dynamic Data Guidelines
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.
Selecting the Data Model
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.
Differences When Working with the ADO.NET Entity Framework
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.
Customizing Data Field Appearance and Behavior
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:
Adding a DataTypeAttribute attribute to properties in the partial class for the entity. For example, by default, a date-time field will be displayed with a date and time string. To display only the time sections of the string, apply the DataTypeAttribute attribute with a DataType of Time. For more information, see How to: Customize Data Field Appearance and Behavior For Non-Intrinsic Data Types in the Data Model.
Creating custom field templates. Use this option when you want to customize appearance and behavior for data fields. You then associate custom field templates with data fields by applying the UIHint attribute to a partial class that extends the data model for the entity. For more information, see How to: Customize Data Field Validation in the Data Model Using Custom Attributes.
Modifying the default field templates in order to use them for non-intrinsic data types. Use this option when you want to customize the data field UI by assigning a type that is more specific to that data field than the CLR type that is inferred by Dynamic Data. For more information, see How to: Customize Data Field Appearance and Behavior For Non-Intrinsic Data Types in the Data Model.
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.
Using ASP.NET Data-Bound Controls in a Dynamic Data Web Site
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:
Enabling dynamic behavior for controls that do not use templates. Use this option if you want to add dynamic behavior to a GridView or a DetailsView control. You add dynamic behavior by using the DynamicField field to render the data fields. For more information, see How to: Add Dynamic Behavior to Data-Bound Controls by Using a DynamicField.
Enabling dynamic behavior for controls that use templates. Use this option if you want to add dynamic behavior to a ListView or a FormView controls. You add dynamic behavior by using the DynamicControl control to render the data fields. For more information, see How to: Use ASP.NET Dynamic Data in Templated Data-Bound Controls.
Customizing dynamic behavior. Use this option if you want to customize the behavior of data-bound controls that use the DynamicControl and DynamicField controls. For example, you can create a custom field template that displays information about quantity ordered. If the value is less than a specified minimum, the data is displayed in red. If the data is greater than a specified maximum, it is displayed in yellow. For more information, see How to: Customize Data Field Appearance and Behavior in a Dynamic Data Control.
Customizing Data Field Validation
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:
Using validation attributes. Use this option if you want to apply additional validation to what is already provided by Dynamic Data, and the System.ComponentModel.DataAnnotations attributes satisfy your requirements. The System.ComponentModel.DataAnnotations attributes define common validation patterns, such as range checking and required fields, that let you use predefined validation checks with very little coding. For more information, see How to: Customize Data Field Validation in the Data Model.
Using custom validation attributes. Use this option if you want to apply additional validation to what is already provided by Dynamic Data and when the System.ComponentModel.DataAnnotations attributes do not satisfy your requirements. You can customize validation for individual data fields by applying custom attributes to the fields. These attributes define validation patterns that you create. For more information, see How to: Customize Data Field Validation in the Data Model Using Custom Attributes.
Using partial class methods. Use this option if you want to apply validation rules when data changes. This approach lets you add business logic to your data model that cannot be handled by the attributes. For more information, see How to: Customize Data Field Validation in the Data Model.
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.
Validation Errors
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.
Using Scaffolding
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:
Enable scaffolding for the site, but hide individual tables. In the data model, create a partial class that extends the table entity, and then add the ScaffoldTableAttribute attribute and set its Scaffold property to false.
Disable scaffolding for the site and then enable it only for individual tables. In the data model, create a partial class that extends the table entity, and then add the ScaffoldTableAttribute attribute and set its Scaffold property to true. For more information about how to work with partial classes as metadata, see How to: Customize Data Field Appearance and Behavior For Non-Intrinsic Data Types in the Data Model.
Disable scaffolding for the site and then enable it only for individual fields. For more information, see the next section.
Make the scaffolded data read-only. For more information, see How To: Create a Read-Only Dynamic Data Web Site.
Use ASP.NET authentication and role providers to limit access to authorized users. For more information, see Securing ASP.NET Web Sites.
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.
See Also
Tasks
Walkthrough: Adding Dynamic Data to an Existing Web Site
Walkthrough: Adding Dynamic Data to an Existing Web Site
Concepts
ASP.NET Dynamic Data Field Templates Overview
ASP.NET Dynamic Data Scaffolding and Page Templates Overview
Reference
Partial Classes and Methods (C# Programming Guide)
Other Resources
Change History
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. |