I promised to continue on the SqlXml generic data layer of my previous post. The last thing I showed you was the code how data is retrieved and stored in the data layer. Next, I would like to tell some more on the way the data is used from the client perspective. The client-code looks something like this:
SqlXmlObjectProvider obj = new SqlXmlObjectProvider();
Hashtable parameters = new Hashtable();
BloggersDataSet ds = (BloggersDataSet)obj.GetObjectData(typeof(BloggersDataSet),
In this fragment a BloggersDataSet is retrieved (the one from the partial fragment in the previous post). It is filled with the blogger data with a primary key equal to the Guid bloggerId. As you can see the type of the DataSet that needs to be returned is specified by a Type object. Also, the name of the XML template and the needed parameter are specified. And that’s it. Pretty simple, right?
What I left out before is the way that the link between an XSD schema file (needed for SqlXml) and the typed DataSet. It’s not possible to ask for DataSet.WriteXmlSchema, because this will return a freshly generated XSD schema that does not contain our SqlXml annotations. Furthermore, we need filenames for the XML templates to perform the queries. So, I designed a config section (and programmed the corresponding section handler) that contains the following:
<addkey=”KillerBlog”value=”PROVIDER=SQLOLEDB;DATA SOURCE=.;INITIAL CATALOG=KillerBlog;INTEGRATED SECURITY=SSPI”/>
The typed DataSets for a project can be stored in whatever assembly you want and are specified by the dataSetType attribute of an <object> element. A directory, in this case D:Killer-BlogDataSchemas contains subdirectories for the XSD schema and the XML templates for every typed DataSet. These are specified by the relativeSchemaPath and schemaFile attributes.
What do you need to run this data layer?
- SQL Server 2000 (SP3 recommended)
- SqlXml 3.0SP1
- .NET Framework 1.0 or 1.1
And for every project, you will need to design and annotate the typed DataSets and their XSD files. These are then configured in the config section. No coding needed, except as a client of the data layer of course. Although I haven’t created it yet, it would be feasible to create tools to facilitate the creation of annotated schemas and XML templates for the queries.
Now for the painful points. What about the limitations I talked about?
Well, here are the ones I can come up with for now:
- The XPath expression inside the XML templates are very limited.
You can hardly use any XPath functions. This makes LIKE queries almost impossible, since substring e.g. is not allowed in SqlXml XPath expressions.
- Comparissons are difficult, since XPath is not/hardly typed. You cannot do comparisons on data types, such as orders[orderDate < 12-2-2002]. Luckily, we can get away with number and dates. With the latter, because the dates are specified as 200T-02-30T12:40 we can do a string comparison that functions as a date comparison, like this: orders[orderDate < “2002-02-12”]. Pfwew.
- There’s no way to do explicit transactions.
There are surely other limitations, but I can’t think of any others at this point.
Of course, I am very interested in your ideas. Please let me know. BTW, I will upload a sample shortly.