There's no doubt that today xml is becoming more and more prevalent as platform-independent data format. Starting SQL server 2005, Microsoft also added tons of support for xml and a new native data type XML, since then I have started to see lots of applications that utilize this data type to run very complex solutions. A new trend is starting to emerge, as one of my colleagues calls it a "paradigm shift", where applications use xml serialized objects (that map to tables) to perform inserts/updates to table rather than having to pass each parameter independently. However, the question remains if this approach is necessarily better than previous?
For example consider the following scenario:
In middle-Tier (.Net Code) my object looks like the following
My serialized xml looks like below:
<Customer customerID="12" customerName="Bigyan" address="123 Redmond Way" phone="123-123-3434"/>
And my call to database stored proc like:
exec Customer_UpdateInformation @customerXml
In parameterized query I would have done something like this:
exec Customer_UpdateInformation @customerID, @customerName, @addresss, @phone
There are both pros and cons to this approach, which I'll explain next. But I also want to clarify that I am NOT advocating one approach vs other, but actually want your opinion on this approach.
Pros:
- Instead of passing 4 parameters, I need to pass only 1. Thus my signature for the database contract is much more succinct.
- If I need to add or modify field, I have less code to deal with and do NOT need to change my signature
- If I am just performing updates on certain fields (not all), I might be able to pass only updated fields and reduce my message size
- Serialization and Deserialization on my .Net objects can be automated, thus reducing effort to map those fields with database fields.
- If I wanted to perform bulk updates, then I have ability to pass multiple elements in my xml; this greatly reduces chatting between .Net and Sql Server.
Cons: