Displaying Custom Classes in a DataGrid, Part 2By Scott Mitchell
In Part 1 we discussed the basics of n-tier architectures and
looked at how we would create our
UserInfo class. In this part we'll look at how to
At this point we have a class to abstractly define a particular user -
UserInfo- but we need some way to define a collection of users. From our collection of users we want to be able to add users, remove users, pick out a particular user, and iterate through all of the users. Sounds like what the .NET collection classes were made for, eh? While we could use one of these .NET collection classes, such as an
ArrayList, we may need to, at some point, add features to the
UserCollectionclass that the
ArrayListdoes not support.
An ideal situation is to use inheritance. That is, our
UserCollection class will inherit
the base functionality of the
ArrayList class, allowing us to reuse the functionality of the
and still be able to add our own functionality at some later point. (For more on inheritance, be sure
to read Ian Stalling's article Using
Object-Orientation in ASP.NET: Inheritance.)
By inheriting the
ArrayList class, the code for our
UserCollection class is quite
minimal, as shown below:
Don't let the short amount of code for the
UserCollection class fool you into thinking
that this class doesn't provide any functionality - it just doesn't provide any original functionality.
UserCollection class is derived from the
ArrayList class it
supports all of the public methods and properties of the
ArrayList class. That is,
one can create an instance of the
UserCollection class and then add elements to the
collection by using the
UserCollection Class in an ASP.NET Web Page
If you've worked with ASP.NET much you're likely well aware of the ease with which ASP.NET allows you to display data. For example, the DataGrid control allows one to display a collection of data in an HTML table with just a few lines of code. (See An Extensive Examination of the DataGrid for more information on the DataGrid Web control.) Essentially, to display data in a DataGrid (or DataList or Repeater) you simply read some data into a DataSet or DataReader, and then set the DataGrid's
DataSourceproperty equal to this DataSet or DataReader. Finally, calling the DataGrid's
DataBind()method renders the DataGrid as an HTML table populated with the data specified in the
DataSource, however, need not be a DataSet or DataReader object. In fact, it can be
any object that implements the
IEnumerable interface, and guess what class
IEnumerable interface? Our
UserCollection class! (It
IEnumerable interface since the
ArrayList class implements this
interface.) Therefore, we can bind a collection of users to a DataGrid.
Not only can we bind a
UserCollection instance to a DataGrid, but the DataGrid is smart
enough when rendering the DataGrid to be able to render the
UserInfo object instances
that reside in the
UserCollection instance that is to be displayed. In fact, in the
DataGrid's Columns tag we can explicitly specify which properties of the
to display. If this doesn't make sense, the following code example should help clear things up:
For this demo to work we need to be sure to copy our .NET components (the DLL files) to the Web application's
Note that to bind a collection of
UserInfo objects to a DataGrid we simply create a
UserCollection object and add some
UserInfo objects to it. We then set our
DataSource property to the
UserCollection object and call
DataBind(). Our DataGrid can then display the various properties of the
As our DataGrid declaration shows, in the Columns tag we can specifically specify what properties of
UserInfo object to show.
Note that we are not limited to using a DataGrid. We could have used a DataList or Repeater control.
To display a property using the databinding syntax you could do:
<# DataBinder.Eval(Container.DataItem, "PropertyName") %>.
Fleshing out the Business Object
At this point the only way a
UserCollectionobject is created is by creating one by hand, and adding
UserInfoobjects to it, as shown in the previous code example. However, from our ASP.NET Web page we would want to be able to call some business object method like
GetUsers()that would retrieve all users from the database, returning a corresponding
UserCollectionobject. Ideally you'd want to create a class, perhaps one named
UserMethods, that would have a public, shared method called
GetUsers()that would return a
UserCollectionobject. This pseudocode might look like:
Once you had this function written you'd want to compile the component and deploy the DLL to the Web
/bin directory. After compiling and deploying this DLL you could display
a list of all the users from an ASP.NET Web page by using the following simple code:
Pretty easy and concise, eh? The benefit of using business objects is illustrated in the above example.
Note that the ASP.NET Web page that displays a list of users can be ignorant to the database structure.
That is, the ASP.NET Web page only cares about the
UserMethods.GetUsers() interface. If
the underlying database structure is altered, only the business objects have to be changed - the ASP.NET
Web pages that utilize the business objects will just keep on working.
In this article we have examined what business objects are and where they fit in an n-tiered architecture. The advantage of an n-tiered architecture is that each tier of the architecture need only be concerned with its neighboring tiers. That is, in our last example, the ASP.NET Web page only needs to know about the business objects and the Web browser. It does not need to know about the database makeup at all. This approach leads to quicker development time, fewer bugs, and more maintainable code. In addition, we saw just how easy it was to display custom classes through an ASP.NET Web page using a DataGrid.