Avoiding the use of XmlDocument

[Dan Kelley]

I have an application which sends messages to an external application. All data is submitted as a string in an Xml format specified by the other application, along with some custom elements we have added to assist in trouble shooting. The format is below

<AppName><Data><![CDATA[our data goes here]]></Data><CustomField1>field 1 data here</CustomField1><CustomField2>field 2 data here</CustomField2></AppName

Currently this Xml is being created dynamically each time a message is being sent, using an XmlTextWriter. What I would like to do is define the skeleton Xml once (when our component is first initialised), and simply set the element values and send this

I can see that I could do this with an XmlDocument, perhaps loading it from an Xml file when initialised, and then working on a Clone of the doc, and setting the value of each node by calling SelectSingleNode for each

In some simple tests, the above is very slow. Does anyone have a better solution

Thanks for your hel
Dan

[Oleg Tkachenko [MVP]]

Dan Kelley wrote:

Currently this Xml is being created dynamically each time a message
is being sent, using an XmlTextWriter. What I would like to do is
define the skeleton Xml once (when our component is first
initialised), and simply set the element values and send this.

You can create a class (either by hands or using xsd.exe) and serialize
object of this class with values set using XmlSerializer instead.

--
Oleg Tkachenko [XML MVP, XmlInsider]
http://blog.tkachenko.com

[Jiho Han]

Although xml serialization is the approach I take for all my business
objects, I sometimes use simple string substitution as I have seen done by
some applications also. I guess it depends on your requirement but if your
xml - assuming *string* - to be sent is not too big and you could just use
String.Format.

I usually don't do this for "objects" but for "formatted messages" where the
format is usually static and don't really require a lot of my classes to
manipulate during the course of processing. Usually one method takes an
object or some values and fills in the blanks for the message and sent.

Oleg,
do you see any issues with this kind of approach?

"Oleg Tkachenko [MVP]" <oleg@NO!SPAM!PLEASEtkachenko.com> wrote in message
news:uX**************@TK2MSFTNGP09.phx.gbl...

Dan Kelley wrote:

Currently this Xml is being created dynamically each time a message
is being sent, using an XmlTextWriter. What I would like to do is
define the skeleton Xml once (when our component is first
initialised), and simply set the element values and send this.

You can create a class (either by hands or using xsd.exe) and serialize
object of this class with values set using XmlSerializer instead.

--
Oleg Tkachenko [XML MVP, XmlInsider]
http://blog.tkachenko.com

[Oleg Tkachenko [MVP]]

Jiho Han wrote:

Although xml serialization is the approach I take for all my business
objects, I sometimes use simple string substitution as I have seen done by
some applications also. I guess it depends on your requirement but if your
xml - assuming *string* - to be sent is not too big and you could just use
String.Format.

I usually don't do this for "objects" but for "formatted messages" where the
format is usually static and don't really require a lot of my classes to
manipulate during the course of processing. Usually one method takes an
object or some values and fills in the blanks for the message and sent.

Oleg,
do you see any issues with this kind of approach?

Well, the only issue with working with XML as with string is XML syntax
issue. It's a way easy to build a string, which isn't well-formed XML.
XML API, such as XmlDocument or XmlWriter help here a lot, so when
whoever doing this by hands (I mean not using XML API) should take care
of XML syntax details, such as escaping of < and & (CDATA helps here),
characters not allowed in XML, encoding etc. No big deal actually, but a
bit fragile stuff. You are right, it depends on requirements and
sometimes (usually simple cases) String.Format is just fine, sometimes -
not.
--
Oleg Tkachenko [XML MVP, XmlInsider]
http://blog.tkachenko.com