I miss the .Net remoting days when I could just send an object over the wire and it would work on both sides of the middle layer without much work. Here's why:
I've been given an assignment. I'm building a Logic/Data Abstraction layer (stupid PCI Compliance) so that we can move our database servers off of the corporate network into a protected network. I did a project like this once under .Net 2.0 with remoting. I built the object on the middleware layer and sent that object to the client and the client had my .Net object to work with. But WCF requires serialization to be able to send stuff up and down the pipe and serialization takes away from my fancy methods that do incredible things with the fields I have in place.
I've come up with two different strategies to get around this: (1) Move the methods from the class itself to a static utility class and (2) "Deserialize" the data on the client side and rebuild the native object with data from the serialized object.
nativeObject.Name = serializedObject.Name;
The flaw of the second method is that I have to re-serialize the object before I can send it back to the middleware layer.
serializedObject.Name = nativeObject.Name;
Both methods work but it is making writing objects take much longer than it should because of the whole serialization mess that the middle layer is causing. I would go back to .Net Remoting, but the architect says he wants this Abstraction Layer done in WCF because (my words, not his) it's new and sexy.
So how does one go about working with .Net native objects on both sides of a WCF connection... without writing 1,000 lines of glue code.