• Choose a category
• All
• Classic-Fiction

By Root 5471 0

use with ObjectDataSource must have a default parameterless constructor. Furthermore, the class should not maintain any state. (The main drawback of static methods is that they might trip you up when it comes to unit testing the DAL, if you ever do it.)

The worker class must be accessible from within the .aspx page and can be bound to the ObjectDataSource control, as shown here:

TypeName="DAL.EmployeeRepository"

SelectMethod="LoadAll" />

When the HTTP runtime encounters a similar block in a Web page, it generates code that calls the LoadAll method on the specified class. The returned data—a collection of Employee instances—is bound to any control that links to MyObjectSource via the DataSourceID property. Let’s take a brief look at the implementation of the LoadAll method:

public static EmployeeCollection LoadAll()

{

var coll = new List();

using (var conn = new SqlConnection(ConnectionString)

{

var cmd = new SqlCommand("SELECT * FROM employees", conn);

conn.Open();

var reader = cmd.ExecuteReader();

HelperMethods.FillEmployeeList(coll, reader);

reader.Close();

}

return coll;

}

Although it’s a bit oversimplified so that it can fit in this section, the preceding code remains quite clear: you execute a command, fill in a custom collection class, and return it to the data-bound control. Binding is totally seamless.

The method associated with the SelectMethod property must return any of the following: an IEnumerable object such as a collection, a DataSet, a DataTable, or an Object. Preferably, the Select method is not overloaded, although ObjectDataSource doesn’t prevent you from using an overloaded method in your business classes.

Using Parameters

In most cases, methods require parameters. SelectParameters is the collection you use to add input parameters to the select method. Imagine you have a method to load employees by country/region. Here’s the code you need to come up with:

TypeName="DAL.EmployeeRepository"

SelectMethod="LoadByCountry">

PropertyName="SelectedValue" />

The preceding code snippet is the declarative version of the following pseudocode, where Countries is expected to be a drop-down list filled with country/region names:

string country = Countries.SelectedValue;

EmployeeCollection coll = Employees.LoadByCountry(country);

The ControlParameter class automates the retrieval of the actual parameter value and the binding to the parameter list of the method. What if you add an [All Countries] entry to the drop-down list? In this case, if the All Countries option is selected, you need to call LoadAll without parameters; otherwise, if a particular country/region is selected, you need to call LoadByCountry with a parameter. Declarative programming works great in the simple scenarios; otherwise, you just write code.

void Page_Load(object sender, EventArgs e)

{

// Must be cleared every time (or disable the viewstate)

ObjectDataSource1.SelectParameters.Clear();

if (Countries.SelectedIndex == 0)

ObjectDataSource1.SelectMethod = "LoadAll";

else

{

ObjectDataSource1.SelectMethod = "LoadByCountry";

ControlParameter cp = new ControlParameter("country",

"Countries", "SelectedValue");

ObjectDataSource1.SelectParameters.Add(cp);

}

}

Note that data source controls are like ordinary server controls and can be programmatically configured and invoked. In the code just shown, you first check the selection the user made and, if it matches the first option (All Countries), configure the data source control to make a parameterless call to the LoadAll method.

You must clean up the content of the SelectParameters collection upon page loading. The data source control (more precisely, the underlying view control) caches most of its properties to the view state. As a result, SelectParameters is not empty when you refresh the page