January 16, 2021
Hot Topics:

Create Quick Database Interfaces with ASP.NET Dynamic Data

  • By Jani Järvinen
  • Send Email »
  • More Articles »

Connecting to the model

With the entity data model created and added to your project, you are ready to connect the model to the rest of the application. In ASP.NET Dynamic Data applications, there is something called a metamodel, to which you can connect either a LINQ or an ADO.NET Entity Framework context.

The metamodel contains information about the database which you wish to edit using your ASP.NET Dynamic Data application. It also contains details about which tables should be visible, how columns should be formatted, and so on.

The metamodel is initialized in the Global.asax code behind file, which is a logical place to register application-wide settings. Code in the Global.asax file (and its code behind file Global.asax.cs) is executed when the ASP.NET application loads, i.e. just before the first page is served.

If you take a look at the default implementation, you will see a long comment about how the metamodel should be registered. The last line of the comment is an actual code line (around line number 29), and you should uncomment and then edit this line to connect or register your data source with the application. Assuming you have an entity model named NorthwindEntities, then the code line should look like this:

    new ContextConfiguration() {
      ScaffoldAllTables = true

Note how you don't need to specify an instance of your data model; it is enough to specify the type of the class using the C# typeof operator. Internally, ASP.NET Dynamic Data uses reflection to gather the necessary data at run-time.

Next, you need to understand the concept of a scaffold. In ASP.NET Dynamic Data, a scaffold specifies which database tables and their fields belong to the editable objects in the resulting application. By default, no tables are visible in the application, but for testing purposes, you could enable every table and all their fields to be editable. This can be done by setting the ScaffoldAllTables property to true, as shown in the previous code listing.

With these registrations in place, you can now run the application. The default page of the application lists all the tables in your data model (Figure 5), and each table name is also a link. Clicking a link allows you to go to a page that displays the records on that particular table (Figure 6). If you take a look at the records, you can see that these listing pages also contain links to create new records as well as edit and delete them. By default, these edits are done using separate pages. However, ASP.NET Dynamic Data also supports in-place editing on the data grids.

Click here for larger image

Figure 5. The default view for a Dynamic Data application.

Click here for larger image

Figure 6. A default list page showing customer records.

ASP.NET Dynamic Data is also intelligent: if the model (and thus the underlying database) has referential integrity set between tables, then your web application will have links from one table to its related tables. In the sample database, a customer can have multiple orders. Thus, the listing for the Customers table contains an automatic link to the orders by this customer. Similarly, from an order page there is an automatic link to order detail rows.

Seeing how Dynamic Data applications are built

After taking a stroll through the generated web application and its many built-in features, it is a good time to close the browser and return to Visual Studio. Next, you are going to learn how ASP.NET Dynamic Data applications are constructed.

First, you can see that your project contains a special folder called DynamicData. This is the default name for this folder, but you can also customize its name by setting the DynamicDataFolderVirtualPath property of the metamodel class in the Global.asax.cs file.

The DynamicData folder contains several subfolders, of which you need to be aware. Four important folders are Content, CustomPages, FieldTemplates and PageTemplates. By design, the Content subfolder contains common resources such as logos and other images used by the application (the actual layout is done using a master template named Site.master). CustomPages folder is initially empty, but it is designed to be a placeholder for your pages that you might want to create for individual tables. That is, by default in ASP.NET Dynamic Data applications, all tables share the same look and feel for their listing and editing pages. Now, if you wanted to have a different page for inserting, say, customer and order records, then you could store your alternative layout pages under the CustomPages folder.

The next two subfolders are key to the operation of ASP.NET Dynamic Data applications. First, there is the folder called FieldTemplates. This folder contains around a dozen user controls, each of which is used to render certain types of database fields. For instance, for Boolean fields, the Boolean.ascx control is used, and for VARCHAR fields, the Text.ascx control is used, and so on. ASP.NET Dynamic Data determines the type of each column based on the model, and then decides which control to render.

The PageTemplates folder contains a set of regular .aspx files. There are three types of files for the basic database operations: creating (Insert.aspx), reading (List.aspx) and updating (Edit.aspx). The fourth basic operation, deletion, is handled by the List.aspx page.

Armed with this knowledge, you can open any of these files and see how they are built. Recall that the same .aspx pages (and their code behind files) are used for every table available in the model. Thus, the pages are not generated statically based on the model, but instead are formed at run-time based on the model. Because of this, you can see that the code in the .aspx files refers often to an object named table, which is a variable defined in the page class.

This object, actually of type MetaTable, contains meta- information about a selected table; the object itself is initialized in the Page_Load event handler. In the .aspx file, the code then refers to members like table.DisplayName and table.GetActionPath.

Page 2 of 4

This article was originally published on June 8, 2009

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date