This series of posts will show you my way of implementing search pages using .Net and AJAX.
In
Part 1, I created client side functions that collect the form values regardless of the actual contents of the form (allowing adding and changing the form without having to update any code)
by the end of that post we got the search parameters to the server side and now we need to implement the search itself.
We already have a web service with a DoSearch method, now we need to create the business logic and data access layers.
I prefer creating separate projects for each layer but you can place these classes in the same project if you like.
Let's start with the BL layer.
I'm going to create a DoSearch method that accepts the same SearchParameters object we received from the client side in the web service.
Because I'm going to use the same methods to execute all searches in the application I need to know which procedure to use. The QueryName property of SearchParameters can be used for that.
You can simply send the name of the stored procedure if you're using one database and you're not worried about the sp name being known.
For these two reasons I decided to send a name that I will use to get the actual query details.
I'm keeping the query details for searches in my application in a table called DataQueries
Table DataQueries
QueryId
QueryName
DBName - the name of the database to use for this query
SPName - the name of the stored procedure to execute
In the actual application I also had some other properties used for permissions testing and application management, so this solution gives you a lot more flexibility
Because the same procedure will be executed many times (different search parameters, paging, or different users) I want to get the query parameters only once and cache them.
The business layer DoSearch method:
public DataSet DoSearch (IshaiHachlili.RapidBackOffice.Entities.
SearchParameters searchParams)
{
//Get the query details from the cached queries
QueriesBL.QueryDetails qd = QueriesBL.GetQueryByName(searchParams.QueryName);
SearchesDL dl = new SearchesDL();
DataSet ds = dl.DoSearch(qd.SPName, qd.DBName, searchParams);
return ds;
}
QueryDetails represents a single row of the DataQueries table. The first time a search is run I get a dataset with all the queries, convert it to a Dictionary with the QueryName and QueryDetails class and save the dictionary into the cache. (The code for this will be included in the download with the last post, but it's pretty basic)
Not much happening in the BL layer right now, but we'll get back to it later, for now, let's skip to the DAL.
Executing the search
I'm using the Enterprise Library's Data Application block for data access, so all I have to do is create a Database object using the passed DBName and execute the stored procedure using the SPName and searchParameters.
public DataSet DoSearch(
string SPName,
string DBName, IshaiHachlili.RapidBackOffice.Entities.
SearchParameters searchParams)
{
Database db = DatabaseFactory.CreateDatabase(DBName);
DbCommand cmd = db.GetStoredProcCommand(SPName);
//Add form input search parameters for this search query
foreach (
QueryParameter fld
in searchParams.Parameters)
{
db.AddInParameter(cmd, fld.FieldName, fld.FieldType, fld.FieldValue);
}
//Add common parameters (all search stored procedures should have this parameters and support paging and sorting functionality)
db.AddInParameter(cmd,
"PageIndex",
DbType.Int32, searchParams.PageIndex);
db.AddInParameter(cmd,
"PageSize",
DbType.Int32, searchParams.PageSize);
db.AddInParameter(cmd,
"SortColumn",
DbType.String, searchParams.SortColumn);
db.AddInParameter(cmd,
"SortOrder",
DbType.String, searchParams.SortOrder);
DataSet ds = db.ExecuteDataSet(cmd);
return ds;
}
Passing the DBName to CreateDatabase allows using different connections for each search, so you can use different databases and different servers.
Currently the Data Application block supports Sql Server and Oracle, but I've only tested this code with Sql Server.
Also, the connection name refers to the connections saved in Web.Config.
You can also see that I'm using the FieldType property for each QueryParameter when I'm adding parameters to the command.
There are ways to "discover" the expected data type but it was much easier to simply add a property to the HTML form elements.
Stored Procedures
All search stored procedures should accept the specific search parameters, and the paging and sorting parameters and return a table with the results and another table with the total row count (one row and one column)
We need the number of rows so we can display the pager in the client side.
The best way to do this is with dynamic sql inside the stored procedure.
I don't really like using dynamic sql anywhere, I think it complicates maintenance and could cause problems that you will only find out when running the actual code and not when compiling, but after trying other solutions with temporary tables and other methods, this was by far the most efficient.
Business Logic Layer - Proccessing the results
In order to support formatting and links in the search results grid, I had to save some properties for each column.
These properties include some styling properties (width, position, alignement), formatting properties, action properties and permissions.
Some of these should be processed on the server side. for example, if a user doesn't have the permission to see a column, I want to remove it from the results before sending it back to the client side instead of just hiding it in the browser.
I also want to send the column definitions back to the client side where I can do the rest of the processing when the grid is created.
The ColumnCollectionName property is used just for that, it's a reference to a collection of column properties saved in the database.
I could've saved this property in the DataQueries table, but separating the column collection and the query used for a search page allows using the same data query in different pages that require different result columns or formatting.
The business layer DoSearch method - updated to support column processing:
public DataSet DoSearch (IshaiHachlili.RapidBackOffice.Entities.
SearchParameters searchParams)
{
//Get the query details from the cached queries
QueriesBL.QueryDetails qd = QueriesBL.GetQueryByName(searchParams.QueryName);
SearchesDL dl = new SearchesDL();
DataSet ds = dl.DoSearch(qd.SPName, qd.DBName, searchParams);
DataSet processedDS = UtilitiesBL.ProcessDataTable(ds.Tables[0], searchParams.ColumnCollectionName);
processedDS.Tables.Add("TotalRows");
processedDS.Tables["TotalRows"].Merge(ds.Tables[1], true, MissingSchemaAction.AddWithKey);
return processedDS;
}
When ProcessDataTable is done with the server side processing, the DataTable holding all the column definitions is merged into the returned dataset.
A third table is added called TotalRows. this table will hold the total row count.
The next posts will explain the server side processing in more details, returning the resutls to the client side and displaying the grid.
Files:
AjaxSearchSamplePart2.zip (849.73 kb)
DataBasesPart2.zip (31.4 MB) (The AjaxSearchSQL and AdventureWorks databases)
Subscribe