The definition of objects for use on the view tier is conceptually platform independent. A class is defined with a variable that provides access to its instance. Then there is a question of what scope the instance would live in.

The scopes are generally application, session, request and page, in the order of their width; application scope being the widest. This is however not universal. For component platforms that keep the page state, this would be kept across requests. Furthermore, there could be a conversation scope across multiple pages. Notwithstanding, the concepts here are relatively uniform across the platforms.

Although there is the code behind class that is associated with the page like the backing beans on some platform, there is no real separation. The code behind are partial classes that would end as one with the implementation class for the aspx page. Backing bean serve as transfer objects on some platforms.

The definition of the data objects used on the page is through data source components. There are varieties of such controls that allow working with different types of data sources such as a database, an XML file, or a middle-tier business object.

• LinqDataSource
• EntityDataSource
• ObjectDataSource
• SqlDataSource
• AccessDataSource
• XmlDataSource
• SiteMapDataSource

The descriptor is mostly suited to object oriented design. However, for legacy application and for those that enjoy the ease of linking tables directly to elements on the page, there is still an accommodation for non-object oriented approach. All placeholders provided in the descriptor for package/namespace, object and attribute, could accept in their place entries for database, table and field.

It is along the following lines that the placeholder for the behavior-define descriptor attributes are translated for use with ASP.NET.

Code Behind

This corresponds to the in-built definition for backing “bb”. This could be explicitly defined in a descriptor as shown below; since defaults could be generated using the IDE that is based on the page-id, this is not necessary.

Example of such specification is shown below.

  Since this class is actually part of the view, a short description of how it holds data and how they are used on the aspx page now follows.

Any publicly defined attribute within the code behind would be accessed. This attribute must be initialized before the use, like in the page load event.

  /* Declare the variable to be bound */
  public string TestData;

  protected void Page_Load(object sender, EventArgs e)
  {
  		/* Initialize the variable to be bound */
  		TestData = "Hello Workld!\n";
  		Page.DataBind();
  }

<asp:Literal text="<%# TestData %>" runat="server"/>
  

It should be noted that apart from the initialization, the invocation of the binding method for the page is needed to populate the control that is bound to the attribute.

Data Source

The data sources are the means of declarative data definitions on the page. Some of these are listed above. It is the LinqDatasource that is used for the translations in this dictionary. This data source is object oriented, using O/RM to abstract the data structure through mappings. By implementing the main entities as partial classes, it allows the easy addition of business layers, a validation method as well as other related facilities.

Example of data source specification is shown below; the explanation on the entries is provided with the details of the descriptor attributes.

This is declared on the page as shown below.

<asp:LinqDataSource ID="CategoryDataSource" 
     ContextTypeName="NorthwindDataContext"
     TableName="Products"
     Runat="Server"/>

The specification and implementation example shown above is minimalistic. Since the business logic surrounding what object should be exposed to the view is controlled by the data source, other issues like sort order, could be part of the implementation.

Some of these other details could be difficult to accommodate, because they are in the realm of details that usually kept in the controller logic. However, the parameters used by data source could easily be accommodated. These parameters are listed below:

DeleteParameters
GroupByParameters
InsertParameters
OrderByParameters
OrderGroupsByParameters
SelectParameters
WhereParameters
UpdateParameters

A data source specification is shown below, that uses the WhereParameters.

It is to the datasource defined above that the following parameters are attached.

The implementation would be as shown below.

  <asp:LinqDataSource ID="CategoryDataSource" 
     ContextTypeName="NorthwindDataContext"
     TableName="Products"
     AutoGenerateWhereClause="true"
     Runat="Server">
    <WhereParameters>
      <asp:ControlParameter 
      Name=" CategoryID" 
      ControlID="SelectedCategoryID" 
      Type="String" />
    </WhereParameters>
  </asp:LinqDataSource>

In the example above, the parameter value is derived from a control. An example of control supplying filtering parameter for another control is the dependent drop down, like selecting a state in order to obtain the list of cities in the state.

It is also possible that the parameter comes from a query string; the specification and implementation of this is illustrated below.

The implementation would be as shown below.

 <asp:LinqDataSource ID="CategoryDataSource" 
     ContextTypeName="NorthwindDataContext"
     TableName="Products"
     AutoGenerateWhereClause="true"
     Runat="Server">
    <WhereParameters>
      <asp:QueryStringParameter
      Name="SelectedCategoryID" 
      QueryStringField="SelectedCategoryID" />
    </WhereParameters>
  </asp:LinqDataSource>