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?