Parameters and ParameterSets
Many queries need parameters to go with them. If the query is for reading then the parameters act as filters and search criteria to the returned data. If the query is for writing then the parameters also carry the actual data to be stored away. For "write" queries these parameter lists can get quite long and cumbersome so
ParameterSets provide a convenient
container for them so that a query only has to remember the ParameterSet name and not each and every individual Parameter. Through configuration we can tie a list of Parameters to a ParameterSet and a ParameterSet to a Query. See the
Configuration page for details on how to do this.
ParameterSets
The developer normally does not need access to the ParameterSet or its list of parameters as all parameters and their values are passed into a query through a simple
IDictionary<string, object> generic dictionary object. Internally the QAB uses the ParameterSet to parse the dictionary object and validate that it has been given the right number and type of parameters.
Having said this there are occasions when a developer may need to get at the ParameterSet and Parameters, especially in a
Custom Command. To do this a
ParameterSetFactory static type exists:
[C#]
// create a ParameterSet with a configured name of "EmployeeSet"
IParameterSet employeeSet = ParameterSetFactory.CreateParameterSet("EmployeeSet");
Parameters
A Parameter, in its most basic form, is essentially just a name and a value. The name would match a particular named parameter in a data query, service call or file element. For example in an XML file query the parameter name would match the name of an attribute or child element of the configured data element in the XML file itself.
Parameters can be obtained from the
ParameterCollection held within a ParameterSet:
[C#]
// create a ParameterSet with a configured name of "EmployeeSet"
IParameterSet employeeSet = ParameterSetFactory.CreateParameterSet("EmployeeSet");
// now get at the parameters
ParameterCollection parameters = employeeSet.Parameters;
In configuration the parameter
Name is set but the parameter
Value is set within your code.
Data Parameters
Data Parameters are used for nearly all data queries and add
DbType data type and
Direction information to data query parameters so that you can state the data type and direction (
In,
Out or
InOut) of your parameters. ADO.NET parameters can take specialized data types like
MySqlDbType, however the QAB integrates with the DAAB and not directly with ADO.NET so only generic
DbType data types are supported.
DataSet Parameters
These are sometimes referred to as
DataAdapter parameters in that they are used when the data source is a
DataSet. This parameter type adds two
additional properties to the ones used for Data Parameters. They are
Column for the source column name from the DataSet and
Version for the row version from the DataSet.
Name Value Parameters
This is the most simple and generic form of a parameter and simply offers an instantiable type from the abstract
Parameter type holding a name and a value only.
XML Parameters
There is nothing too special about XML parameters either in that we normally only need a name of an
Attribute or
Element and a value to search for or replace etc. However, in complex XML files that use namespaces then we also need a namespace to be able to uniquely find attributes and elements within our XML data file. So an XML Parameter simply adds a
Namespace property to the existing Name and Value properties.
Custom Parameters
It is quite likely that a situation could arise where data is required from a parameter type that is not supported. Examples might include a
BaseDn and
filter pair for an LDAP query etc. For this you can create a
custom parameter by inheriting from
Parameter which in turn implements the
IParameter interface. You use the
Attributes property to define the specific properties of your new parameter type. For more details refer to the
Extending the Query Application Block page.