January 2005 - Posts

• Kiss the Middle-tier Goodbye with SQL Server Yukon

  The article Kiss the Middle-tier Goodbye with SQL Server Yukon which claim:   Yukon's new XML support features cut out the middleman and allow you to deal with your data directly on the database tier. Learn how to use these features to improve your database app's performance and design. by Klaus Aschenbrenner. Caught my eyes..   How its reflect our architecture considerations and specifically to the way we will design our DAL layer? R we going to keep only a rudimentary DAL layer and move the CRUD actions to the DB server? A typical DAL will most likely to have something like -   void Save(string xmlTableData) {     //call the DB store procedure save with the parameters - xmlTableData of type Xml }   Today I saw another presentation regards Yukon. Part of the Xml features I already saw within Oracle DB by using custom packages. Still, I got the impression that Microsoft thoroughly attacked the Xml support within SQL Server. Yukon support lots of the XQUERY W3C language.   Partial Yukon Xml features list: We can use scheme to enforce constraints on Xml column but we can still work without it Select, add, delete data from an Xml column within a DB table  Construct Xml structure as part as select statement using XPath Get Xml parameter and convert it to tabular structured and vice versa We saw part of the XQUERY FLWOR implementation which enable us to manipulate our Xml data using FLWOR expressions   Immediate advantages to keep our data as Xml in the DB: We enjoy our DB capabilities - backups, replication etc Transaction operation on our data With Yukon we will have strong set of options to manipulate Xml data before its being save to the DB Table and before we return it back to the client We have flexible data format that can easily enhance and stretch in future releases   Considerations/Note: The performance implication when processing Xml within our server is still unknown on this stage. We sure need to take this point into consideration. [note - our table is lock when updating our Xml columns. Huge Xml will effect the lock time and effect all the other users, Right now, rational operation have better response time]    Impression: As I see it - Yukon and other RDBS with rich  Xml support will be another architecture option in our application architecture DAL alternative.  I think whoever have to Kiss his DAL is welcome to do it - but saying goodbye will be too soon.   Other goodbye estimations:  Kiss goodbye your Component Service Layer (because of Transaction namespace) Kiss goodbye your Integration services layer (we have Biztalk and such) Kiss goodbye your web client front end (click once) Kiss goodbye NUnit (we have build in testing tools in Whidbey) Kiss goodbye WSE2, 3 and so (Indigo) Kiss goodbye part of your web developers (we have lots of out of the box, productive web controls and infra structure in Whidbey, meaning less work)   Any other ideas?   Posted Jan 17 2005, 09:11 PM by guyS with 5 comment(s) Filed under: Data Layer Focus

• Using XSL Transform with Objects Extension[framework2]

  In continue to the previous post here is another great walkthrough by ftponline web site author Thiru Thangarathinam regard XSLT performance but I find it also focus on object extensions during XSL transform process. This time its being done using the new XslCommand class that ship with Framework2 and is the core class for dealing with XSLT transformations. Here is a snippet of it XsltCommand command = new XsltCommand(); //Compile the XSL stylesheet    command.Compile(Server.MapPath    ("ProductsPaging.xsl")); XmlArgumentList argsList = new    XmlArgumentList(); //Retrieve the pageNumber from //querystring int pageNumber = Convert.ToInt32(    Request.QueryString["pagenumber"]); //Add the required parameters to the XmlArgumentList object argsList.AddParameter    ("recordsPerPage", "", 10); argsList.AddParameter    ("pageNumber", "", pageNumber); argsList.AddParameter    ("recordCount", "", 77); //Instantiate the object to be added to the //XsltArgumentList object BGColor obj = new BGColor();    argsList.AddExtensionObject    ("urn:myColor",obj); command.Execute(xpathDoc, null, argsList,       Response.Output); I guess that we will be able to see more and more object extensions in our applications for validations, filtering & sorting according to a set of rules, different text formatting and such.  One of the intensive usage I can see for object extension will be in Yukon, which is the code name for the next SQL Server. Yukon introduce a new table field type of Xml. Its also enable us to use our assemblies for processing data within the database itself. This mean we could get our Xml data from a table field, process it in our assembly using XSL with object extensions and return it to our client - and do it all within our DB XML processing within Yukon can also be done using internal set of XQuery language that is part of Yukon. So we can now choose the best processing method for our problem.  Posted Jan 07 2005, 02:32 AM by guyS with no comments Filed under: Data Layer Focus