The Query Application Block QuickStart Sample Application

The sample that is supplied with the Query Application Block is contrived to demonstrate all of the features of the Query Application Block and was, in fact, derived from the Test Console used in the System testing of this block.

Note: before trying out the samples please check the configuration files with the Enterprise Library Configuration Console. The samples use file based providers (XML File Queries) with absolute path names. These files are quite likely to be in a different place on your computer as they were on mine. You may also need to update the WCF and Web service references. In addition to checking the configuration you will also need to install the sample Query database. This can be done by running the CreateQueryDb.cmd install script found in the EntLibContrib.Query.Database source code in the Scripts folder.

The following shows the main form divided into radio button triggered queries on the left, parameter data entry fields on the right and results display below:

The Test Console

The test form always starts with the control query which is simply a pre-populated DataSet bound to the DataGrid just to make sure that the tester is correctly displaying data bound from a DataSet. The QAB is not involved with this query but is for all others. The Data Entities are a little confusing because they derive from a sample database for the Martin Fowler Patterns of Enterprise Application Architecture implementation in C# project that I put together, of which the QAB forms a part. A Basic entity is a straight forward data entity with a single Guid identifier, the User table holds login accounts and the Owner table holds the "who owns this record" hierarchic relationship between users and records in all other tables. The meaning of these tables and their content, however, bears no significance to this sample application. The other rather confusing concept, although mitigated by the group box titles, is that a Basic1 operation relates to a Data Query on the Basic table, a Basic2 operation relates to a Service Query on the Basic table and a Basic3 operation relates to a File Query (XML Query) on the Basic table. Finally, if the word Object appears in the query title then that operation is being handled by a Custom Command.

Each radio button is wired up to a Click event handler and a typical Read query looks like the following:

[C#]
/// <summary>
/// A radio button click event handler for reading all active records from the "Basic" table held in a relational database.
/// </summary>
private void rdoBasic1_Click(object sender, EventArgs e)
{
	IQuery query = QueryFactory.CreateQuery("Read Basic1");
	DataSet ds = query.ExecuteForRead();
	ds.Tables[0].TableName = "Basic1";
	BindToGrid(ds);
}


This code results in the following display:

Test Console Read Basic1 Query

Note that the query tester tests write operations too, the following is an example:

[C#]
/// <summary>
/// A radio button click event handler for updating all the records held in a DataSet from the "Basic" table held in a relational database.
/// </summary>
private void rdoBasic1Update_Click(object sender, EventArgs e)
{
	DataSet ds = (DataSet)dataGridView1.DataSource;
	if (ds.Tables[0].TableName != "Basic1")
		MessageBox.Show("You must have the Basic1 Dataset on display to use this command");
	else
	{
		foreach (DataRow row in ds.Tables[0].Rows)
		{
			QueryFactory.CreateQuery("Update Basic1").ExecuteForWrite(CreateBasic1UpdateParameterDataSet(row));
		}
		MessageBox.Show("the Basic1 Data has been updated");
	}
}

private IDictionary<string, object> CreateBasic1UpdateParameterDataSet(DataRow row)
{
	IDictionary<string, object> parameters = new Dictionary<string, object>();
	parameters.Add("Id", row["Id"]);
	parameters.Add("SampleString", row["SampleString"]);
	parameters.Add("SampleDate", row["SampleDate"]);
	parameters.Add("SampleBoolean", row["SampleBoolean"]);
	parameters.Add("SampleInt", row["SampleInt"]);
	parameters.Add("SampleDecimal", row["SampleDecimal"]);
	parameters.Add("OwnerId", row["OwnerId"]);
	parameters.Add("UpdatedUserId", userId);
	parameters.Add("UpdatedDate", DateTime.Now);

	return parameters;
}


The SampleString for two of the records in the "Basic" table was changed to Updated 1 and Updated 2 respectively, in this example of the above code, resulting in the following display:

Test Console Basic1 Update Query

Several of the queries take parameters. The data entry fields for these parameters are on the right-hand side of the form with three helper buttons to populate some of these fields from data displayed on the bottom:
  • New Id - this button will generate a new Guid and place the results in the Id field.
  • Get Id - this button will copy the Id value of the top record in the current display into the Id field.
  • Get OwnerId - this button will copy the OwnerId value of the top record in the current display into the OwnerId field.
The following shows the result of a parameter-based query:

Test Console Read Basic1 By Id Query

To get a grasp of the mechanics of the QAB from this sample application it is recommended to look at the app.config using the Enterprise Library Configuration Console and the source code for the QueryTester. The important thing to note is how little code was required to read and write data.

A Note About the Service Queries in the QuickStart Application

The QAB has been written to support both the newer WCF Services within the .NET 3.5 Framework and the older legacy Web Services from the .NET 2.0 Framework. Using Service Queries with the QuickStart application you can only test either the (WCF) services OR the (Web) services depending on what version of the Framework that you compile the code with, or rather depending on whether you use VS2005 or VS2008. This is because the Service References are in the same assembly. The author uses VS2008 so the WCF service interfaces have been tested thoroughly but the Web ones not so well and the QuickStart Application will come to you biased towards VS2008 and .NET 3.5. The services themselves are written in the correct versions it is just the Service References in the Query Tester console that can only be one or the other.

Custom Commands Used in the Sample Application

As per my recommendation all custom commands used in this sample application are held in a separate assembly EntLibContrib.Query.QuickStart.CustomCommands.dll. The following is an example of a query using a custom command that sorts the records in alphabetic order of the SampleString:

Test Console Read Basic1 Object Sort Query

Note: from the perspective of the application the mechanism of the query is transparent. The application has no knowedge, nor care, that a custom command is being applied.

Last edited Dec 23, 2009 at 12:51 PM by ewdev, version 7

Comments

No comments yet.