Dynamic Data

  • Article

It is July – and for us at Microsoft that signals the end of one fiscal year and the start of a new one. It has been a bit busy for us and hence the pause in our activity. We resume now with Part 8 of Paul Cociuba’s ASP.NET series.

So far in the tutorial series we have been focusing on working with data through Entity Framework Code First, and letting the ORM determine the way in which the database should look based on the C# classes we defined in the application. In this video, I take the concept one step further in that we would also need to user interface to be driven by the code of the business logic layer of our application. In this way, there would be a single control point (the code) from which the user interface and the database would be created and driven from. To achieve this we will be using Dynamic Data, which is a scaffolding template to build the user interface based on the model.

1:48 – since the last tutorial , the application has been augmented with two more navigation controls on the master page to allow the user to quickly get to the products and the category listings page. This is done by using LogInView controls that only display markup if the user is logged in and part of the SiteAdministrators group in our case.

3:25 – when building our the model classes with C#, I have showed that we can override Entity Framework conventions with attributes such as the [Key] attribute to indicate the primary key column. These attributes reside in the System.ComponentModel.DataAnnotations namespace.

4:10 – we further augment the model classes by adding more attributes to further define the way in which Entity Framework defines the database. Attributes such as [Required] – to indicate that a column does not allow null values, [StringLength(100)] – to indicate that the text can be of maximum 100 characters long, or [Display(Name=””)] will aid Entity Framework when building out the database.

The [DataType(T)] attribute takes in a value from the DataType enumeration to indicate what type of data we would like to store in a particular property of an entity. This enumeration contains values such as CreditCard, Email, HTML, etc, which will also be clues for Dynamic Data on how to create the user interface when scaffolding.

6:15 – If a desired type is not found in the DataType enumeration, the DataType attribute can also be used as shown for the Price property of the Product entity: [DataType(“Integer”)], where the string designating the desired data type replaces the values coming from the enumeration. The usage of the [Range()] attribute allows us to also specify a valid range of numbers (with a minimum and a maximum) for a specific property, like the price or the units in stock.

7:10 – The first time the web-application was run, Entity Framework created the database in SQL server based on the model classes that we had defined at the time. For example, the Name column of the Products table in the SQL dataset was of type NVarChar(MAX) and allowed for null values, as the model did not indicate a maximum length of a string in the Name property of the Product entity, nor did it specify that the Name property could or could not be null.

7:50 – Running the web-application after the model classes have been modified / augmented with the new attributes will lead Entity Framework to detect that there are changes needed to be made to the database. It will mitigate these changes by dropping the old database and creating a new one in its place with the constraints defined on the model.

8:20 Inspecting the types of the columns in the SQL database after running the project again shows how the constraints defined via attributes were built into the SQL database by Entity Framework. The Name column of the Products table is not of type NVarChar(100) and no longer allows nulls because of the use of the [StringLength()] and the [Required] attributes.

9:25 – To allow the code of the model entities to also drive the look and feel of the web-interface, we will bring in the Dynamic Data scaffolding framework. To do this, I use the Nuget package manager and chose the Dynamic Data for Entity Framework Code First package.

9:50 – Installing Dynamic Data from Nuget will add several folders to the project structure. The FieldTemplates folder is of particular interest since it will contain all the templates needed to display different types of data. These templates are actually UserControls (ascx) that Dynamic Data will pick from when it was to display such types as Email, Text, etc. The name of the user control matches the name of the type to be displayed.

10:55 – The grid views for the Products.aspx and Categories.aspx used BoundField controls to display the data in the columns on the screen. We replace these with DynamicField controls, which will allow Dynamic Data to pick the correct template from the FieldTemplates folder to display the data coming from the model.

11:45 – Running the sample after the modification shows that the GridView controls are actually displaying the column headers as well. The values of the headers come from the [Display(Name=””)] attribute usage from the model classes. Hence, the interface is now starting to be driven by the model code.

14:05 – The next modifications are on the CategoryDetails.aspx and ProductDetails.aspx FormView controls. The text boxes used to display data in the InsertItemTemplate and the EditItemTemplate are replaced by DynamicControls. This allows Dynamic Data to look up the corresponding edit templates from the FieldTemplates folder based on data type and replace the markup of the DynamicControls with the markup generated by these templates.

15:30 – For the Price property of the Product entity, an attribute of type [DataType(“Integer”)] was used to decorate the property. We now create a filed template called Integet_Edit.ascx to indicate to Dynamic Data that this is the field template to be used when displaying this type of data in insert or edit mode.

17:05 – Running the project again after making these changes and attempting to edit an existing product shows that the markup is similar to one that was generated in the earlier version of the application. Some changes are evident though: the Description field of the Product is now displayed as a multi-line text box, and this is due to the fact that an attribute of type [DataType(DataType.MultiLineText)] was used on the model.

18:00 – Running the sample application in a browser such as Opera and attempting to edit a product shows that the Price and UnitsInStock textboxes no longer display the range selection arrows characteristic to HTML 5. To correct this, a change needs to be implemented in the Integer_Edit.ascx field template – the textmode attribute of the textbox in the template needs to be changed to Number instead of SingleLine.

20:05 – Further usage of Dynamic Data could involve the creation of entity templates in the EntityTemplates folder. Instead of just using templates for displaying a field type, Dynamic Data can be used to display templates for complex types, such as the ToyCategory or Product objects, allowing a uniform look and feel of the interface in the entire project.

The next video in the series will attempt to look at implementing validation rules based on the model classes and Dynamic Data.

References

Original content from Paul Cociuba; posted by MSPFE editor Arvind Shyamsundar