ASP.NET Dynamic Data Layer Customization

The data layer contains a model that represents the entities in a database and how these entities relate to each other. Through the data model, you can control the appearance and behavior of data entities and perform automatic validation with little or no code. You can also customize the appearance and behavior (such as validation) for these data entities.

This topic contains the following sections:

• Background

• Selecting the Data Model

• Displaying Data Fields

• Validating Data Fields

• Dynamic Data Attributes

• Additional Information

Background

When you create a new project in Visual Studio, you can select the LINQ to SQL Classes or the ADO.NET Entity Data Model template. This selection determines the type of model that is used by the project. In the data model, ASP.NET represents data entities as CLR types. Dynamic Data uses these types to query the database and to perform create, read, update, and delete (CRUD) operations. The models also provide a way to integrate business logic.

At run time, Dynamic Data automatically extracts metadata information from the data model, such as data field properties. From this information, it infers how to create UI for displaying and editing data. To render the UI, it uses the following information:

• Information about associations between tables is used to display foreign-key columns and to support navigation between tables.

• Data-type information is used to add validation and to select the appropriate field templates for a data field. For example, information about columns that allow null values can be used to determine whether a data field is required. Length information can be used to restrict the maximum length of user's text input. The data type of a field is used to determine which field template to use to render the UI for that field.

Selecting the Data Model

LINQ to SQL and the Entity Framework have many features in common. However, each has features that target different scenarios. LINQ to SQL is targeted more toward quickly developing applications using an existing Microsoft SQL Server schema. The Entity Framework provides objects and storage-layer access to SQL Server databases and to third-party databases.

LINQ to SQL

LINQ to SQL has features that target Microsoft SQL Server database. It provides a strongly-typed view of an existing database schema. LINQ to SQL supports a direct, one-to-one mapping of the existing database schema to .NET Framework classes. A single table can be mapped to a single class and foreign keys can be exposed as strongly-typed relationships.

Using LINQ to SQL, you can build LINQ queries over tables, views, and so on, and return results as strongly typed objects. You can also call stored procedures that return strongly typed results through strongly typed methods. A key design principle of LINQ to SQL is that it works for the most common cases. For more information, see LINQ to SQL [LINQ to SQL].

ADO.NET Entity Framework

The ADO.NET Entity Framework targets enterprise scenarios. In an enterprise, the database is typically controlled by a database administrator. The schema is usually optimized (for performance, consistency, partitioning, and storage) instead of for exposing an application model that directly reflects the schema. The schema might change over time as usage data and usage patterns evolve. The Entity Framework exposes an application-oriented data model that is loosely coupled and that might differ significantly from the actual database schema.

For example, you can map a single class (or entity) to multiple tables or views, or you can map multiple classes to the same table or view. You can map an inheritance hierarchy to a single table or view (as in LINQ to SQL) or you can map it to multiple tables or views. This flexible mapping is specified declaratively, and does not require the application to be recompiled if the schema of the database evolves over time.

The Entity Framework includes LINQ to Entities, which exposes many of the same features that LINQ to SQL provides. For more information, see ADO.NET Entity Framework.

Displaying Data Fields

Dynamic Data uses the data model metadata to render the UI for displaying and modifying data fields. Rendering is accomplished by using user controls that are known as field templates.

To render a data type, Dynamic Data performs a search through the data model, looking for classes that have the UIHintAttribute attribute applied. If the attribute exists, it specifies which field template to render the UI for a particular data type. If no attribute exists, Dynamic Data searches for a field template whose name matches the data field type. (For more information about templates, see ASP.NET Dynamic Data Scaffolding.)

Dynamic Data lets you customize and extend the UI that is rendered for a data field in the following ways:

• Extending the data model through custom metadata. You can use System.ComponentModel.DataAnnotations attributes to assign metadata to data fields to customize the related UI. For example, you can use the UIHintAttribute attribute to associate a custom field template with a data field. You use this approach to change the appearance and behavior of an individual data field for a specific database. For more information, see Walkthrough: Customizing Data Field Appearance and Behavior in the Data Model.

• Assigning a non-intrinsic type to a data-field type. You can use the DataTypeAttribute attribute to mark fields by using a data type that is more specific than the database intrinsic type. The type name is selected from the DataType enumeration type. For example, a string data field that contains an e-mail addresses can be specified as the EmailAddress type. For more information, see How to: Customize Data Field Appearance and Behavior For Non-Intrinsic Data Types in the Data Model.

Validating Data Fields

By default, Dynamic Data supports data-field validation based on the metadata, which includes the following default rules:

• Required-field validation. If a data field cannot be null, Dynamic Data enforces that a value is provided for the field.

• Length validation. If a database field is a string, Dynamic Data enforces the maximum length of the field.

• Type validation. Dynamic Data enforces that the user's input value matches the intrinsic data type for a data field.

You can provide the following additional validation information in the data model by using System.ComponentModel.DataAnnotations attributes and by creating validation methods:

• Customizing validation for individual data fields by applying Dynamic Data System.ComponentModel.DataAnnotations attributes to the fields. These attributes define common validation patterns, such as range checking and required fields. You should use this approach when you want to add validation to what is already provided by Dynamic Data, and when the default System.ComponentModel.DataAnnotations attributes are sufficient for your requirements. For more information, see How to: Customize Data Field Validation in the Data Model.

• Customize validation for individual data fields by creating custom validation attributes. This approach lets you expand the validation that is provided by the System.ComponentModel.DataAnnotations attributes. This is useful if the available attributes do not meet your validation requirements for a specific data field.

• Customize validation for an individual data field by overriding the OnValidate method or handling the Validate event, which are invoked when any data field is changed. This approach lets you add validation and business logic for an individual field. This approach is more general than adding validation for an individual field. It is useful when the same validation logic can be applied to more than one data field. It also lets you perform validation checks that involve multiple fields.

For more information, see How to: Customize Data Field Validation in the Data Model Using Custom Attributes

Generating Validation Errors

The System.ComponentModel.DataAnnotations attributes enable you to raise custom errors or use the built-in errors when validation fails. For this reason, the validation attributes can take any one of the following named error parameters:

• ErrorMessage. This parameter specifies the error message that is associated with a validation control. You use this parameter to specify a non-localizable custom error message and to optionally override the default localizable message.

• ErrorMessageResourceName. This parameter specifies the error message resource that is associated with a validation control. You use this parameter to specify a resource file that contains localizable error messages

• ErrorMessageResourceType. This parameter specifies the type of error message that is associated with a validation control. You use this parameter to identify the error message as defined in the resource file. The resource file is specified by using the ErrorMessageResourceName parameter.

You can customize validation error messages in the following ways:

• You can use the default error messages that are always localized. In that case, you do not have to specify any of the parameters listed previously.

• You can provide a non-localizable custom error message that overrides the default message by using the ErrorMessage parameter.

• You can provide a resource error message file that can be localized by using the ErrorMessageResourceName parameter. You then specify the error message that is contained in the resource file by using the ErrorMessageResourceType parameter.

Dynamic Data Attributes

By applying attributes in the System.ComponentModel.DataAnnotations namespace to data fields in the data model, you expand the data model by providing information that Dynamic Data uses to customize data entities. The following table shows the attributes and their intended use.

You can also use System.ComponentModel attributes to customize the data fields. The following table shows some of these attributes and their intended use.

Additional Information

For more information about Dynamic Data, see the following topics:

• For more information about URL routing, see ASP.NET Routing.

• For more information about LINQ-to-SQL Object-Relational mapping, see LINQ to SQL [LINQ to SQL].

• For more information about the ADO.NET Entity Framework, see ADO.NET Entity Framework.

• For more information about partial classes and methods, see Partial Classes and Methods (C# Programming Guide) and Partial Methods (Visual Basic) (for Visual Basic).

Back to top

See Also

Tasks

Walkthrough: Creating a New Dynamic Data Web Site Using Scaffolding

Walkthrough: Adding Dynamic Data Scaffolding to Existing ASP.NET Web Sites

Concepts

ASP.NET Dynamic Data

ASP.NET Dynamic Data Scaffolding

ASP.NET Dynamic Data Presentation Layer Customization

ASP.NET Dynamic Data Presentation Layer Customization