Practical ASP.NET

Supporting the ObjectDataSource

You're considering the ObjectDataSource but you're not an object developer. Peter Vogel shows you what you need to do to move into multi-tier development.

• By Peter Vogel
• 03/31/2010

I started out programming on mainframe computers (I'm very old) and segued through Visual Basic and Access development before getting on the Web with ASP and Visual InterDev. My next move was into object-oriented development -- only after that did I move to ASP.NET. Given that history (object development preceding ASP.NET development), it's not surprising that the ObjectDataSource was a natural choice for me to use.

However, as I discussed in my last column (In Defense of Single-Tier Applications), any number of developers don't build multi-tier applications and don't use the ObjectDataSource. For developers who are considering multi-tier development but aren't sure how it would integrate into an ASP.NET environment, here's the basics of building objects to use the ObjectDataSource: Object-Oriented Development for the ASP.NET developer.

Implementing the Factory
The ObjectDataSource assumes that you'll follow the Factory Method design pattern (which happens to be a great pattern). The Factory Method pattern uses two classes to support a business entity: One class is responsible for handling the interface between the "database world" and the "object world"; and the other class carries the data. The Customer business entity, for instance, will be supported by a Customer factory and a Customer data class.

To get the advantages of using multi-tier development, you should create a Class Library project in your solution. This allows developers to work on this object project without having to check out the ASP.NET application (and vice versa). The ASP.NET developer will need to add a reference to the Class Library project.

The Customer factory will have methods that accept simple parameters (strings, integers, etc.) and return one or more Customer objects. For instance, a GetCustomerById method will accept a customer Id and return a single Customer object (or Nothing/null if there is no matching customer data). A GetCustomerByCityAndVolume method would accept a city name and a sales level and return all the Customer objects that represent customers in that city who have purchased enough from the company to qualify for the sales level.

To simplify interacting with your middle-tier business objects, the ObjectDataSource assumes that all methods on the Factory class will return a List collection. This doesn't make a lot of sense for those methods that will return, at most, a single Customer object (e.g. the GetCustomerById method I mentioned earlier). Life's like that.

Coding the pattern
I'll start with the simplest method on any Factory class, one that returns a single object retrieved by the primary key for a table. To work with the ObjectDataSource, the method is declared as Shared and returns a List of the related data object:

Imports System.Data.SqlClient
Public Class CustomerFactory
  Shared Function GetCustomerById(CustId as Integer) As List(of Customer)
  End Function
End Class

Within the class, you use some very straightforward ADO.NET code to retrieve your data, pass it to your data class (which I'll discuss in my next column), and add your class to a List:

Dim rdr As SqlDataReader
Dim con As New SqlConnection(...connection string...)
Dim cmd As SqlCommand = con.CreateCommand()
cmd.CommandText = "Select * from tblCustomers Where CustomerId = @Id"
cmd.Parameters.AddWithValue("Id", CustId)

Dim lst As New List(Of Customer)
Dim cst As Customer

con.Open
rdr = cmd.ExecuteReader()
If rdr.Read Then
   cst = New Customer(rdr(0),  rdr(1),  rdr(2), ...)
   lst.Add(cst)  
End If

Return lst

A method that returns multiple objects is only slightly more complicated:

Shared Function GetCustomersByCity(CityName as String) As List(of Customer)
Dim rdr As SqlDataReader
Dim con As New SqlConnection(...connection string...)
Dim cmd As SqlCommand = con.CreateCommand()
cmd.CommandText = "Select * from tblCustomers Where City = @City"
cmd.Parameters.AddWithValue("City", CityName)

Dim lst As New List(Of Customer)
Dim cst As Customer

con.Open
rdr = cmd.ExecuteReader()
Do Until rdr.Read 
   cst = New Customer(rdr(0),  rdr(1),  rdr(2), ...)
   lst.Add(cst)  
Loop

Return lst

End Function

As you can see, the major differences between the two methods are the parameters provided to the SQL statement, and that the code uses a loop to process the results of the query because multiple records can be returned.

Now that you're retrieving data, in my next column I'll look at what you'll need in your data object. Stay tuned!