ASP.NET Dynamic Data Guidelines
[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]
ASP.NET Dynamic Data enables you to select the level of customization appropriate for your needs. This section contains guidelines and suggestions that can help you in performing your tasks.
Dynamic Data lets you quickly create a complete Web application that has full dynamic capabilities. It also lets you easily integrate a database in a Web site and select the specific dynamic capabilities that you require.
ASP.NET Dynamic Data provides an ample range of customization that lets you adapt a Web site to your needs from the presentation layer to the data layer.
If you need to create a data-driven Web site quickly, using ASP.NET Dynamic Data lets you easily create a complete Web application that has full dynamic capabilities. Dynamic Data supports Web scaffolding, which lets you run the application that is based on the data-model with a minimum amount of code, can help you achieve your goal. Although this Web scaffolding has a standard UI, it lets you perform Create, Read, Update, and Delete a (CRUD) operations on your tables. Also, it has full support for relationships. You can use the scaffolding to create a basic application and then apply appropriate customizations later. For more information, see Walkthrough: Creating a New Dynamic Data Web Site Using Scaffolding.
For more information, see ASP.NET Dynamic Data Overview.
ASP.NET Dynamic Data lets you integrate the dynamic data controls behavior in your existing Web site by letting you select the specific dynamic capabilities you require. To do this, you must perform the following steps:
Create a Dynamic Data Web site. For more information, see Walkthrough: Creating a New Dynamic Data Web Site Using Scaffolding.
Create field templates. For more information, see ASP.NET Dynamic Data Field Templates Overview.
Customize the data-model. For more information, see ASP.NET Dynamic Data Model Overview.
Create a custom page to display a table. For more information, see ASP.NET Dynamic Data Scaffolding and Page Templates Overview.
Use data controls that have dynamic behavior. For more information, see ASP.NET Dynamic Data Scaffolding and Page Templates Overview
For more information, see Walkthrough: Adding Dynamic Data to an Existing Web Site.
You can provide additional information to Dynamic Data by using the System.ComponentModel.DataAnnotations attributes to apply metadata to data fields in the data model. Dynamic Data uses this information for example, to customize the way the UI is rendered for data fields display and editing.
Using Validation Attributes
When you apply the validation attributes you must adhere to the following usage constraints:
The attribute can be applied to a property or a field.
The attribute can be applied only one time.
Applying Validation Attributes
The following are the steps that you must follow to apply any System.ComponentModel.DataAnnotations attribute to a data field.
In the App_Code folder of a Web application, implement a class file that includes a data context partial class. This class represents the table that contains the data field to which you want to apply the attribute.
Create another class that will act as the associated metadata class. You can use any name for the class, but the class name must match the name that you reference in the MetadataTypeAttribute attribute applied to the partial class, as explained next. Put this in the same class file as the class you just created.
In the associated metadata class, create a public property or field whose name is the same as the name of the data field to which you must apply the validation attribute.
Apply the MetadataTypeAttribute attribute to the partial class definition. The attribute's parameter is the name of the associated metadata class.
Generating Validation Errors
The System.ComponentModel.DataAnnotations attributes enable you to create custom errors or use the built-in errors when the 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 perhaps 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 contain 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 previous parameter.
The following are the possible choices when using validation attribute error messages:
You can use the default error messages that are always localized. In this case, you do not have to specify any one of the previous parameters.
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. Then you specify the error message this is contained in the resource file by using the ErrorMessageResourceType parameter.
LINQ to SQL and the Entity Framework have much in common, but each has features targeting different scenarios. LINQ to SQL is targeted more toward quickly developing applications against your existing Microsoft SQL Server schema. The Entity Framework provides objects and storage-layer access to Microsoft SQL Server and third-party databases through a loosely coupled, flexible mapping to existing relational schema.
LINQ to SQL
LINQ to SQL has features that target Microsoft SQL Server database. It enables you to have a strongly-typed view of your existing database schema.
LINQ to SQL supports a direct, one to one mapping of your 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.
You can build LINQ queries over tables/views/table valued functions and return results as strongly typed objects, and 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. Therefore,example, if you access a collection of orders through the Orders property of a customer, and that customer's orders have not previously been retrieved, LINQ to SQL will automatically get them for you.
ADO.NET Entity Framework
The ADO.NET Entity Framework has features that target enterprise scenarios. In an enterprise, the database is typically controlled by a database administrator. The schema is generally optimized for storage considerations (performance, consistency, partitioning) instead than exposing a good application model, and may change over time as usage data and usage patterns evolve.
The Entity Framework is designed around exposing an application-oriented data model that is loosely coupled, and may differ significantly, from your existing database schema.
For example, you can map a single class (or entity) to multiple tables/views, or map multiple classes to the same table/view. You can map an inheritance hierarchy to a single table/view (as in LINQ to SQL) or to multiple tables/views. This flexible mapping is specified declaratively in order to account for the schema of the database evolving over time without having to recompile the application.
The Entity Framework includes LINQ to Entities which exposes many of the same features as LINQ to SQL over your conceptual application data model.
For more information, see Introducing LINQ to Relational Data.