If you happen to use RemObjects SDK 4.0 (RO) for an alternative to remoting (I'll discuss the benefits in another post) than you are certainly facing one problem. RO thing doesn't support .net classes as method arguments in favor of interoperability (you can't use .net object graph from a different world, i.e. Delphi, right) - out of the box it supports only common value types (ints, strings, etc.) with some degree of extensibility. This isn't good when you want to push a .net object graph over the wire of course. Transferring .net object graphs works only in .net environment and it is not interoperable with other worlds. So as long as you are doing .net - .net you are fine.
The best option for this scenario is RO's Binary data type, a class derived from MemoryStream in RO.net version. I guess you see where I am going - I'll be doing manual (de)serialization to/from Binary.
Imagine we have a RO service method defined like this:
public Binary DoSomething(Binary args) { ... }
and in reality it should look like this:
public ReturnClass DoSomething(SomeClass args) { ... }
You will have to do some classic serialization:
public ReturnClass DoSomething(SomeClass args)
{
Binary binaryIn = new Binary();
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(binaryIn, data);
binaryIn.Position = 0;
Binary result = DoSomething(binaryIn);
and some classic deserialization:
result.Position = 0;
BinaryFormatter formatter = new BinaryFormatter();
return (ReturnClass)formatter.Deserialize(result);
}
However, when you deal with many methods that require this exercise the task soon becomes annoying. That's why I've created ROHelper class that does much of the (de)serialization for you. With some help of generics here it is:
public class ROHelper
{
public static T ConvertFromBinary<T>(Binary binary)
{
binary.Position = 0;
BinaryFormatter formatter = new BinaryFormatter();
return (T)formatter.Deserialize(binary);
}
public static Binary ConvertFrom<T>(T data)
{
Binary binary = new Binary();
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(binary, data);
binary.Position = 0;
return binary;
}
}
and here is the DoSomething method rewritten:
public ReturnClass DoSomething(SomeClass args)
{
return ROHelper.ConvertFromBinary<ResultClass>(
DoSomething(
ROHelper.ConvertFrom(args)
));
}
Isn't this code much better than spaghetti code above? Also note, that method ConvertFrom<T> doesn't require explicit definition of type T as it is deduced from argument itself.
The only thing that remains to improve is code generation itself. Even with simpler code like this you have to write all those method wrappers. So, the next step is to build code wrapper generator. Next time, perhaps.