1.1. Exploring a Dynamic Data Web Site

To give you a feel for the standard features, begin by creating a Dynamic Data web site.

1.1.1. Prerequisites

Dynamic Data is an out-of-band update to the ASP.NET Framework; therefore, you must have a few extra items installed before you proceed. You must have Visual Studio 2008 installed as well as:

1.1.2. Create the Web Site

Dynamic Data sites are tailor-made for data-driven web applications; therefore, you must have a database available. Create a new database named DDIntro and create the Contact table using the following script:

CREATE TABLE [dbo].[Contact](
[ContactID] [int] IDENTITY(1,1) NOT NULL,
[FirstName] [varchar](50) NOT NULL,
[LastName] [varchar](50) NOT NULL,
[Email] [varchar](75) NOT NULL,
[Url] [varchar](100) NULL,
[PreferredFontSize] [int] NULL,
[CreatedOn] [datetime] NOT NULL,
[ConcurrencyID] [int] NULL,
CONSTRAINT [PK_Contact] PRIMARY KEY CLUSTERED ([ContactID] ASC))

Next open Visual Studio 2008 and create a new Dynamic Data web site (see Figure 1).

Figure 1. Figure 1

Next create an App_Code ASP.NET folder at the root of the web site, and add a new LINQ to SQL class named DB.dbml. Once the DBML file is created, the LINQ to SQL designer will appear. Locate the DDIntro database in the Server Explorer (accessible by [Ctrl]+W,L) and drag the Contact table to the LINQ to SQL design surface. The designer should now look like Figure 2.

Figure 2. Figure 2

Next open Global.asax and locate the commented-out model.RegisterContext line:

//model.RegisterContext(typeof(YourDataContextType), new ContextConfiguration() {
ScaffoldAllTables = false });

Un-comment this line, and replace YourDataContextType with DBDataContext and set ScaffoldAllTables to true. Your code should now look like this:

model.RegisterContext(typeof(DBDataContext), new ContextConfiguration() {
ScaffoldAllTables = true });

The MetaModel class must know about the model of your database in order to build the Dynamic Data screens. The application has no way of knowing what that class is until you create your DBML file, so the default template is set to comment out this line by default.

You also set ScaffoldAllTables to true so that you will automatically have CRUD access to each table in your model via the scaffolding. Should you choose to hide a table from the scaffolding, you can remove individual tables with a simple attribute setting your metadata definition.

For now, run the application and take a look at what is already available to you. The first page displays a list of the tables modeled in your DBML file (see Figure 3).

Figure 3. Figure 3

If you click on the "Contacts" link, you are presented with a list of records in the table. Since this table is new, the list is empty (see Figure 4).

Figure 4. Figure 4

Clicking on "Insert new item" takes you to the data entry screen, where you can insert a new record. This screen is already wired up with validation rules found in the database. For instance, the FirstName and LastName fields are required. An attempt to insert a record when these fields are empty will trigger the RequiredFieldValidators on the page, reminding the user to enter some values.

You may also notice that there is no UI control for ContactID, the primary key value. Since this field was marked at an IDENTITY column, the scaffolding page skips exposing this field to the user as the database will handle maintaining the field's value (see Figure 5).

Figure 5. Figure 5

Once you click on the "Insert" link, you return to the list of records in the table. Now that the table has data, you have an opportunity to delete, edit, and view the details of each record (see Figure 6).

Figure 6. Figure 6

What's important to note at this point is that you have a web site with full CRUD capabilities without having to write one line of data access code. Furthermore, the Dynamic Data features are rich enough to recognize referential integrity and create dropdown lists where appropriate to help handle foreign key relationships.

1.1.3. Building Blocks

There are four foundational building blocks to Dynamic Data: the model metadata, field templates, the DynamicControl, and ASP.NET routing. Each of these parts interacts with the other to help build an appropriate UI for the data members.

1.1.3.1. Model Metadata

The Dynamic Data features hinge on the metadata it gathers about any given data field. Beginning with the field data type and moving down to custom attributes applied by the programmer, the metadata is responsible for describing the field to the web site. For example, text fields are rendered as textboxes and Boolean fields are represented by checkboxes. The default mappings in Dynamic Data will select the appropriate UI controls for the data type.

On top of the default mappings, you can add additional layers to the metadata definitions to add validation logic, change the display text of a field, associate custom UI implementations, and much more. The power of Dynamic Data is driven by the metadata defined for each field.

1.1.3.2. Field Templates

Using the information found in the metadata, Dynamic Data will select the appropriate field template that is responsible for rendering the data to the user. Sometimes the controls will render in Read Only mode. Under different circumstances pages can render edit controls.

Field templates are nothing more than standard ASP.NET user controls that encapsulate the necessary user interface controls. This gives you freedom to create and customize controls that best suit your needs. While Dynamic Data initially pairs data fields with templates based on data type, custom field templates will go a step further to create sets of controls and validation logic that better suit the business logic of the web site.

1.1.3.3. Dynamic Control

The DynamicControl is a new server control introduced with Dynamic Data. The responsibility of the DynamicControl is to act as a placeholder for a field template. When you want to display a data field on the page, you add a DynamicControl in the appropriate location. When the page is executed, the Dynamic Data engine looks at the metadata and locates the correct field template. The selected field template is then rendered where the DynamicControl is placed on the page.

1.1.3.4. Routing

Dynamic Data harnesses ASP.NET routing to provide pages with the table name. When you are browsing to a scaffold page, the table name is given to a page template via the URL. Consider the following route found in Global.asax:

routes.Add(new DynamicDataRoute("{table}/{action}.aspx") {
    Constraints = new RouteValueDictionary(new { action = "List|Details|Edit|Insert" }),
    Model = model
});

This results in a URL like the following to list the contents of the Contact table:

http://localhost:49905/DynamicDataWebsite/Contacts/List.aspx

This approach abstracts away the table from the template pages. This abstraction allows Dynamic Data to provide CRUD pages without having to resort to generating ASPX code for each of the tables.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.220.88.62