XmlDocument Vs StringBuilder

[anup_daware]

Hi Group,

 

You might have found the Title a little strange :); well following is the problem description:

I want to form a SOAP xml request to a servlet, I have my Request xml template ready.

Now I have following options:

1. Load the xml template in an XmlDocument object and manipulate it.

2. Load the xml template in a StringBuilder object, manipulate it and then load it in XmlDocument.

3. Not using any template and creating the xml from scratch.

Following is the sample xml template which I will use:

<?xml version="1.0" encoding="UTF-8"?>
<MT_MaterialSearchRequest>
<!-- Customer Data -->
<CUSTOMER> CUSTOMER _PLACEHOLDER</CUSTOMER>
<SALES_ORG> SALES_ORG _ PLACEHOLDER </SALES_ORG>
<!-- Limit on the size of the search result -->
<DEFAULT_SORTING> DEFAULT_SORTING _PLACEHOLDER</DEFAULT_SORTING>
 <!-- Material Data -->
<WIDTH> WIDTH _HOLDER</WIDTH>
<SERIE> SERIE _HOLDER</SERIE>
<!-- Material List -->
<VISIBILITY_ITEM_IN>
 <ITEM> <!�NOTE: Number of <ITEM> nodes is dynamic>
    <MATERIAL></MATERIAL>
</ITEM> 
<ITEM> 
<MATERIAL></MATERIAL>
</ITEM> 
</VISIBILITY_ITEM_IN>
</MT_MaterialSearchRequest>

 

My Questions:

1. For this scenario which of the above mentioned options which is more suitable?

2. In General which options is more preferable?

3. I know that second option of using StringBuilder is going to be very easy for implementation, but which option is better in terms of speed of execution and memory considerations?

 

Hoping to get some expert comments on this :)

 

Thanks,

Anup Daware

[snarfblam]

I believe that the XmlDocument is very reasonable with memory and performance. With alot of optimization, a StringBuilder could be made to be faster, or more memory efficient, or possibly even both, but this raises the question of whether or not it is that important to optimize this aspect of your program. How frequently will you be performing this processing, and how many documents will you be processing? How large is your document? Most likely, the method that best represents your intention and makes code the simplest would be the way to go. If you are doing some heavy processing, your best bet might be to try both and see which one works better.

[alreadyused]

couple ideas...

 

My two cents, but get another opinion also...

Other than speed and resources, here's something else to consider:

 

#1 would be best suited if you want to be able to change the template down the road without having to recompile/redistribute the code, since you can simply send out a new template for your code to read. Although I haven't tested it, I'm also going to guess it's the slowest, esp. if the template file is remote. But, it might not be enough of a speed difference to matter. I suppose this method could also pose some potential security problems, if someone else can access the template.

 

#2 would be best if you know the template will never need to change unless the code is changing also. Then you create a simple procedure that "builds" your template for you, and there's only one place to go to change that template if you happen to need to modify it. My gut feeling is that this will be faster than reading a document in, but again, just a guess.

 

 

One other note, and maybe you already know this, buy since you said <visibility_item_in> will have a varying amount of <item><material /></item> children, you should have a function that handles appending that. Again, do the speed test, but I think the fastest or most common way to do that is with an xml fragment

to use this you must create a new xml fragment for your document.

'lazy code:
Sub AddItem(strMaterial):void
 xdoc.CreateDocumentFragment
 xFrag.InnerText = "<item><material>" & strMaterial & "</material></item>"
'assuming:
 dim xn as xmlnode = xdoc.SelectSingleNode("//VISIBILITY_ITEM_IN")
 xn.Append(xFrag)
End Sub

Finally, do you need the words "CUSTOMER _PLACEHOLDER ", etc in the innertext? Are you using the length of that to specify how many chars they can enter?

You could put this in your template instead:

<CUSTOMER max="30" />

then access that through:

xn.Attributes(0).Value

or

xn.Attributes("max").value

[anup_daware]

CreateDocumentFragment seem to be very useful :)

 

Hi alreadyused and marble_eater,

 

Thanks for the reply.

 

I was not knowing about CreateDocumentFragment. I found it really useful and I may drop the idea of using a StringBuilder :)

 

Regards,

Anup Daware

 

 

 

 

 

 

 

 

 

 

 

My two cents, but get another opinion also...

Other than speed and resources, here's something else to consider:

 

#1 would be best suited if you want to be able to change the template down the road without having to recompile/redistribute the code, since you can simply send out a new template for your code to read. Although I haven't tested it, I'm also going to guess it's the slowest, esp. if the template file is remote. But, it might not be enough of a speed difference to matter. I suppose this method could also pose some potential security problems, if someone else can access the template.

 

#2 would be best if you know the template will never need to change unless the code is changing also. Then you create a simple procedure that "builds" your template for you, and there's only one place to go to change that template if you happen to need to modify it. My gut feeling is that this will be faster than reading a document in, but again, just a guess.

 

 

One other note, and maybe you already know this, buy since you said <visibility_item_in> will have a varying amount of <item><material /></item> children, you should have a function that handles appending that. Again, do the speed test, but I think the fastest or most common way to do that is with an xml fragment

to use this you must create a new xml fragment for your document.

'lazy code:
Sub AddItem(strMaterial):void
 xdoc.CreateDocumentFragment
 xFrag.InnerText = "<item><material>" & strMaterial & "</material></item>"
'assuming:
 dim xn as xmlnode = xdoc.SelectSingleNode("//VISIBILITY_ITEM_IN")
 xn.Append(xFrag)
End Sub

Finally, do you need the words "CUSTOMER _PLACEHOLDER ", etc in the innertext? Are you using the length of that to specify how many chars they can enter?

You could put this in your template instead:

<CUSTOMER max="30" />

then access that through:

xn.Attributes(0).Value

or

xn.Attributes("max").value