"MJ" <sy******@hotmail.com> wrote in message
news:64**************************@posting.google.c om...
Would defining your methods using Reference Type instead of value
types go someway to delivering what you want without branching?
Yes, this would be a good solution if your scenario merits it. Using an
opaque message-based parameter "blob" that can be serialized over the wire
is a form of service decoupling that saves you from breaking client code
down the road because it's always aggregational - as you "grow" the message
descriptor structure your older clients only have to fill in certain things
and you can compensate for that on the service side very easily. A version
field also helps =)
Normally you'd do this as a mini-SOAP over SOAP, where your 'thing' (no pun
intended <g>) is perhaps a key-value pair style structure that contains
parameters and their values. So, this:
void DoThing(int x, double y) {
...
}
becomes:
void DoThing(string z) {
...
}
where 'z' is maybe something like this:
<xml>
<methodCall>
<param name="x" value="2" />
<param name="y" value="44.5" />
</methodCall>
Now, the problem with this is expressing complex types, which is something
SOAP does well to begin with. But in most cases you can wing it relatively
easy. You "dehydrate" the container before dispatching it (serialization)
and "re-hydrate" it on arrival (deserialization). Mostly straightforward.
A design based on this 'pattern' can be called a "message-based transport
architecture", and some of us were doing that long before SOAP was a gleam
in Don Box's eyes =)
It was actually an excellent way to do additional decoupling for COM-based
services that exposed behavior via independent interfaces that callers would
consume through a configurable programmatic ID. This would save you from
having interfaces that looked like bad Hollywood sequels:
IThing
IThing2
IThing3::DoThing4
....
You could write books about this stuff, really =)
--
Klaus H. Probst, MVP
http://www.vbbox.com/ 
