In my previous two articles, we talked about the use of layers, and the many different options that can be used to develop layered architecture. Layered architectures are essentially objects and work in object-oriented environments, such as ASP.NET. ASP.NET supports layered architecture, and this article will illustrate how it can work with the ASP.NET presentation controls. This article focuses mainly on the GridView control, mostly because it is prevalently used in .NET development. However, the concepts work for other controls as well.
As I mentioned before, the business and data layer are essentially classes that perform a specific function. The data layer’s responsibility is to communicate with the backend structure, such as a database. The business layer is responsible for validating the business rules of the component, and communicating with the data layer. To learn how to set this up, please consult my previous articles. We are now going to retrieve data from the database in an ADO.NET table that gets passed back to the presentation layer. This architecture approach is using a strongly-typed dataset.
The business and data layer retrieve or update the data in a database for an ASP.NET application. Now it is time to retrieve this data and bind it to the presentation layer. The first approach is illustrated below; using a strongly-typed data table, the data is bound to a GridView control.
Listing 1: Binding to an ASP.NET UI Control
The example above connects to the business layer to retrieve orders data for a specific customer. This table is bound to a grid, presenting the users with a list of orders for a specified customer. You can see an example of the GridView structure below.
Listing 2: GridView Interface Markup
The GridView control maps the column structure in the UI to the collection of orders in the data source. The GridView control is essentially a tabular structure that renders one row for each row in the data source. For example, if there were five orders returned from the business layer, the GridView control renders a header row (using the
HeaderText value as the column header), followed by the one row for each of the records in the data table.
At a row level, when the first Order is processed, the GridView creates a cell for each of the columns in the
Columns definition. It starts out processing the Order Date column, extracting the
CreatedDate field from the data row using Reflection. This value is inserted into the cell without any formatting; however, to ensure that only the short-hand version of the date is used, the
DataFormatString attribute specifies to use a short-hand form of
Continuing on, the
TotalAmount field is extracted from the data source, and passed to the next cell for the column “Total Amount.” The value provided is formatted to a two-digit number using the
F2 designation; this ensures only two digits are shown.
The GridView also supports editing or deleting of data in the grid. To easiest way to setup editing and deleting is to set the
AutoGenerateDeleteButton properties to
true. This creates a link for each row in the grid. Clicking on the link triggers the appropriate action. When binding manually, it is your responsibility to tap into the appropriate control and perform the update call to the data layer. This is because the GridView doesn’t know what was originally bound it, and therefore requires another binding to update the interface.
The actual work to be done needs to be performed in the
RowDeleting events. These events are fired when the Update or Delete buttons are clicked. Processing the row requires something like the following:
Listing 3: Updating an Order
In order for this to work, the data needs to be extracted from the UI controls holding the updated data, which are TextBox controls (which is what the BoundField data field uses). If the UI would have been the TemplateField, a similar approach can still be used here. To delete data, use the following:
Listing 4: Deleting an Order
Deleting an order is more simplistic than updating because only the key is needed.
If you want to sort or page in the grid, these need handled using the
Sorting events as well. If these events are not handled (including the ones handled previous), an exception is thrown because the GridView control does not know what to do in a manual binding situation. Essentially this approach requires the same amount of work as was done in the .NET framework 1.x version with the DataGrid control.
Manual Binding Caveats
As you can see, a sizable amount of code is required to implement a manual binding approach; it’s not overtly difficult to do this, but binding using the new DataSourceControl architecture (discussed next) works more smoothly and seamlessly.
Data Source Control Alternative
When the 2.0 framework was released, the DataSourceControl architecture featured a whole new way to bind data to the UI controls. The goal was to make the overall process simpler, while reducing the amount of code it took to manage the different control states (like the DataGrid's edit/readonly state changes). In most cases, ASP.NET development can use this architecture without having to write any (or at least very minimal) code. The control that works with layered architectures is the ObjectDataSource control. This control uses Reflection to pass data to and from the business layer.
This approach affects the options you have when binding data. The ObjectDataSource control works well with data that is primitive or value type data. This is because the object data source can serialize it and store it in viewstate, or deserialize it from a string value (when it’s stored in the
DefaultValue property). If you are a fan of passing in object-references to your methods (for instance, pass in an object instead of the object's key), then the following approach won't work:
Listing 5: Method With Business Object – Doesn’t Work with ObjectDataSource
Instead, in order for the ObjectDataSource to call this method, it needs the following structure:
Listing 6: Method With Integer – Doesn Work with ObjectDataSource
From a user interface standpoint, the UI controls in the .NET framework work well with the DataSourceControl controls. Whenever these UI controls need access to the data, the bound DataSourceControl makes a call to the database, returns the data or performs the correct operation. All of that occurs seamlessly.
For example, with the GridView control bound to an ObjectDataSource, whenever it needs to refresh the data, the GridView gets an instance of the underlying bound data source and makes a call to the name of the method specified for the
SelectMethod property. To call this method, the ObjectDataSource constructs the business object specified in the
TypeName property and invokes the name of the method (defined in SelectMethod) through Reflection. Any parameters specified in the
SelectParameters collection are passed along to the method as well.
These controls can also work with insert, update, and delete operation, as long as all of the parameters are setup correctly. For instance, to setup an ObjectDataSource for these operations and connect to a component, use the following approach:
Listing 7: ObjectDataSource Setup
In the above example, the select method doesn’t have any parameters, so no parameters are defined. For insert and update operations, each of these methods exposes a signature similar to the one below.
Listing 8: Objects Business Layer Setup
The difference with
UpdateOrder is that the key is defined in the
DataKeys collection of the Grid. The values are passed from the GridView control and passed to the method through a Reflection call. The Reflection call assigns the parameters correctly to the method based on matching the parameter names.
Some parameter types retrieve their values from an external source; ControlParameter extracts a value from the control it maps to, SessionParameter taps into the Session collection, QueryStringParameter taps into the query collection; etc. Notice my previous implementation used the regular Parameter class; this is sufficient for the GridView. Parameter also has a
DefaultValue property that takes a string representing any default value you choose.
Data Source Control Caveats
These new controls utilize binding in a new way; however, it’s hard to control the process when used. Each operation occurs in a specified way, with a little room for adjustment. Every situation isn’t immediately clear what the problem may be. For instance, TemplateField columns cannot automatically add their property value to the dictionary of values in the event.
In addition, some architectures are better suited for a manual binding situation, even though it involves more code. In some situations, the ObjectDataSource control doesn’t suffice.
The .NET framework comes with the DetailsView and FormView controls, which work similar to the GridView control. Other controls, such as the Repeater or DataList use a template to bind to. This means that the entire UI for each row is totally up to you. For instance, check out the following:
Listing 9: Repeater Setup
As an alternative, some of the other controls take a more simplistic approach to data binding. All that is required is to supply the field that is bound as the text or the value, as shown below:
Listing 10: Drop Down List Setup
When the source is bound to the DropDownList, a new ListItem is created for each row. The text of the ListItem is supplied from the
TotalAmount field, and the value of the ListItem object is supplied from the
This article discussed how ASP.NET architecture can use a layered approach to bind data to the presentation layer. In each of these samples, the ASP.NET control architecture already defines the plumbing to bind data using a DataSourceControl object, as well as supporting manual binding.
Brian Mains is an application developer consultant with Computer Aid Inc. He formerly worked with the Department of Public Welfare.
In both places of business, he developed both windows and web applications, small and large, using the latest .NET technologies. In addition, he had spent many hou...
This author has published 73 articles on DotNetSlackers. View other articles or the complete profile here.
Please login to rate or to leave a comment.