Question

I’m writing some software that modifies a Windows Server’s configuration (things like MS-DNS, IIS, parts of the filesystem). My design has a server process that builds an in-memory object graph of the server configuration state and a client which requests this object graph. The server would then serialize the graph, send it to the client (presumably using WCF), the server then makes changes to this graph and sends it back to the server. The server receives the graph and proceeds to make modifications to the server.

However I’ve learned that object-graph serialisation in WCF isn’t as simple as I first thought. My objects have a hierarchy and many have parametrised-constructors and immutable properties/fields. There are also numerous collections, arrays, and dictionaries.

My understanding of WCF serialisation is that it requires use of either the XmlSerializer or DataContractSerializer, but DCS places restrictions on the design of my object-graph (immutable data seems right-out, it also requires parameter-less constructors). I understand XmlSerializer lets me use my own classes provided they implement ISerializable and have the de-serializer constructor. That is fine by me.

I spoke to a friend of mine about this, and he advocates going for a Data Transport Object-only route, where I’d have to maintain a separate DataContract object-graph for the transport of data and re-implement my server objects on the client.

Another friend of mine said that because my service only has two operations (“GetServerConfiguration” and “PutServerConfiguration”) it might be worthwhile just skipping WCF entirely and implementing my own server that uses Sockets.

So my questions are:

• Has anyone faced a similar problem before and if so, are there better approaches? Is it wise to send an entire object graph to the client for processing? Should I instead break it down so that the client requests a part of the object graph as it needs it and sends only bits that have changed (thus reducing concurrency-related risks?)?
• If sending the object-graph down is the right way, is WCF the right tool?
• And if WCF is right, what’s the best way to get WCF to serialise my object graph?

Answer 1

Object graphs can be used with DataContract serialization.

Note: Make sure you’re preserving object references, so that you don’t end up with multiple copies of the same object in the graph when they should all be the same reference, the default behavior does not preserve identity like this.

This can be done by specifying the preserveObjectReferences parameter when constructing a DataContractSerializer or by specifying true for the IsReference property on DataContractAttribute (this last attribute requires .NET 3.5SP1).

However, when sending object graphs over WCF, you have the risk of running afoul of WCF quotas (and there are many) if you don’t take care to ensure the graph is kept to a reasonable size.

For the net.tcp transport, for example, important ones to set are maxReceivedMessageSize, maxStringContentLength, and maxArrayLength. Not to mention a hidden quota of 65335 distinct objects allowed in a graph (maxObjectsInGraph), that can only be overridden with difficulty.

You can also use classes that only expose read accessors with the DataContractSerializer, and have no parameterless constructors:

using System;
using System.IO;
using System.Runtime.Serialization;

class DataContractTest
{
    static void Main(string[] args)
    {
      var serializer = new DataContractSerializer(typeof(NoParameterLessConstructor));

      var obj1 = new NoParameterLessConstructor("Name", 1);

      var ms = new MemoryStream();
      serializer.WriteObject(ms, obj1);

      ms.Seek(0, SeekOrigin.Begin);

      var obj2 = (NoParameterLessConstructor)serializer.ReadObject(ms);

      Console.WriteLine("obj2.Name: {0}", obj2.Name);
      Console.WriteLine("obj2.Version: {0}", obj2.Version);
    }

    [DataContract]
    class NoParameterLessConstructor
    {
        public NoParameterLessConstructor(string name, int version)
        {
          Name = name;
          Version = version;
        }

        [DataMember]
        public string Name { get; private set; }
        [DataMember]
        public int Version { get; private set; }
    }
}

This works because DataContractSerializer can instantiate types without calling the constructor.