Question

I have a legacy HTTP/XML service that I need to interact with for various features in my application.

I have to create a wide range of request messages for the service, so to avoid a lot of magic strings littered around the code, I’ve decided to create xml XElement fragments to create a rudimentary DSL.

For example.

Instead of…

new XElement("root", 
  new XElement("request",
    new XElement("messageData", ...)));

I’m intended to use:

Root( Request( MessageData(...) ) );

With Root, Request and MessageData (of course, these are for illustrative purposes) defined as static methods which all do something similar to:

private static XElement Root(params object[] content) 
{
    return new XElement("root", content);
}

This gives me a pseudo functional composition style, which I like for this sort of task.

My ultimate question is really one of sanity / best practices, so it’s probably too subjective, however I’d appreciate the opportunity to get some feedback regardless.

1. I’m intending to move these private methods over to public static class, so that they are easily accessible for any class that wants to compose a message for the service.

2. I’m also intending to have different features of the service have their messages created by specific message building classes, for improved maintainability.

Is this a good way to implement this simple DSL, or am I missing some special sauce that will let me do this better?

The thing that leads me to doubt, is the fact that as soon as I move these methods to another class I increase the length of these method calls (of course I do still retain the initial goal of removing the large volume magic strings.) Should I be more concerned about the size (loc) of the DSL language class, than I am about syntax brevity?

Caveats

Note that in this instance the remote service poorly implemented, and doesn’t conform to any general messaging standards, e.g. WSDL, SOAP, XML/RPC, WCF etc.

In those cases, it would obviously not be wise to create hand built messages.

In the rare cases where you do have to deal with a service like the one in question here, and it cannot be re-engineered for whatever reason, the answers below provide some possible ways of dealing with the situation.

Answer 1

I noticed this article for constructing arbitrary XML with C#4.0 which is great.

The source for the library is here – https://github.com/mmonteleone/DynamicBuilder/tree/master/src/DynamicBuilder

At this time, there is a notable deficiency, no xml namespace support. Hopefully that will get fixed though.

As a quick example, here’s how it’s done.

dynamic x = new Xml();
x.hello("world");

Which yields:

<hello>world</hello>

Here’s another quick example yanked from the article.

dynamic x = new Xml();

// passing an anonymous delegate creates a nested context
x.user(Xml.Fragment(u => {
    u.firstname("John");
    u.lastname("Doe");
    u.email("[e-mail]");
    u.phone(new { type="cell" }, "[phone]");
}));

Which yields:

<user>
    <firstname>John</firstname>
    <lastname>Doe</lastname>
    <email>[e-mail]</email>
    <phone type="cell">[phone]</phone>
</user>

Having used the Ruby library Builder this method of creating arbitrary XML is similarly terse, to the point that it verges on “fun”!

I’ve marked this as the answer, because, even though it doesn’t directly speak to “using a DSL to create arbitrary XML” it tends to remove the need due to the extremely terse and dynamic nature of the syntax.

Personally I think this is the best way to create arbitrary XML in C# if you have the v4.0 compiler and have to crank it by hand, there are of course much better ways to generate XML automatically with serialization. Reserve this for XML which must be in a specific form for legacy systems only.