CODEWITHSUNDEEP
c#xmldsllegacy
ocodo
ocodo

Reputation: 30248

Implementing a DSL in C# for generating domain specific XML

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.

Upvotes: 6

Views: 1065

Answers (4)

ocodo
ocodo

Reputation: 30248

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("[email protected]");
    u.phone(new { type="cell" }, "(985) 555-1234");
}));

Which yields:

<user>
    <firstname>John</firstname>
    <lastname>Doe</lastname>
    <email>[email protected]</email>
    <phone type="cell">(985) 555-1234</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.

Upvotes: 1

Jonathan Dickinson
Jonathan Dickinson

Reputation: 9218

Have you noticed that all the System.Linq.Xml classes are not sealed?

public class Root : XElement
{
    public Request Request { get { return this.Element("Request") as Request; } }

    public Response Response { get { return this.Element("Response") as Response; } }

    public bool IsRequest { get { return Request != null; } }

    /// <summary>
    /// Initializes a new instance of the <see cref="Root"/> class.
    /// </summary>
    public Root(RootChild child) : base("Root", child) { }
}

public abstract class RootChild : XElement { }
public class Request : RootChild { }
public class Response : RootChild { }

var doc = new Root(new Request());

Remember this won't work for 'reading' scenarios, you will only have the strong-typed graph from the XML that your application creates via code.

Upvotes: 2

Michael Kay
Michael Kay

Reputation: 163322

Writing this in C# seems an awful lot of work. Design your DSL as an XML vocabulary, and then compile it into XSLT, writing the compiler (translator) in XSLT. I've done this many times.

Upvotes: 0

tom redfern
tom redfern

Reputation: 31760

Hand-cranking xml is one of the things which should be automated if possible.

One of the ways of doing this is to grab the messaging XSD definitions off your endpoint and use them to generate C# types using the xsd.exe tool.

Then you can create a type and serialize it using the XmlSerializer, which will pump out your xml message for you.

Upvotes: 1

Related Questions