C# obtain return code from a proxy

dcof

Question: best place to obtain return code from a proxy I am enhancing on a C# 2008 application that calls a web service. This application was written by the contract shop that has the web service. I am just adding what I need to this application for my company's needs. One change I am making is for my company to have a tracking table. This table is used to keep track of the types of calls that have been made to the web service for each of our customers. "My question is the best place to obtain the return code from the web service". Right now there is a proxy that is used in this application to call the web service. The proxy contains the return code from the web service. Thus I am looking for best place to obtain the return code from the proxy and how would you make the coding change from the list below and/or other options you can think of: 1. Can I put my code in the proxy? I would not touch the exact location where the web service is called. Is this a good idea or not? 2. When I use the proxy I would change it to a function. The value returned from the function call would be the value I am looking for. 3. I would pass an extra parameter to the proxy call to it would give me the return code. if I chose this option, how would I obtain the value that is optional a return value from the proxy call?

dojohansen

It depends. It *always* depends. :) I would try to look for a solution that could keep the tracking stuff separate from the proxy. Proxies usually aren't hand-coded and it's quite convenient to just "update" a "service reference" in order to generate new proxy code should the service interface change. Assuming you only use a few operations on the service, the easiest seems to me to be adding a thin abstraction layer on top of the proxy and put the tracking logic there. A few tips for how to do such refactoring speedily: - Rename the proxy class to whatever you want your new class (implementing the abstraction layer) to have, using Refactor => Rename. This will update all the call sites. - Rename the class back to what it was originally called, WITHOUT using Refactor => Rename. Every place in the code where you had new Proxy() you now have new AbstractionLayer(). (Please don't use that name. Name it according to what function it has.) Introduce the new class and put your tracking logic there. In short, you've built a proxy for the proxy.

Pete OHanlon

Thank you, this saves me having to answer the question. Of course, I would use the term Facade rather than AbstractionLayer. My 5 anyway.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

dojohansen

Well that's what we get with metaphores. If you're speaking pattern what you're saying may be well-defined, but as long as we just use metaphores things are always kinda vague. A proxy is a kind of facade and also a kind of abstraction layer, wouldn't you say? But to my mind, the facade metaphor is a little inappropriate here because the thing about a facade is that it looks completely different from what it's hiding. That's usually the point of having a facade, to cover the ugly stuff. :) A proxy on the other hand looks just like the thing it is a proxy for. So here I think we're making a proxy for the proxy. But rather than start explaining all this and use "metaproxy" I resorted to the more general conception of an abstraction layer. Of course, in practice one would only expose those bits of the interface that one actually uses. So then I suppose it kinda acts as a facade too... Gee it's hard to say anything sensible about this stuff. As a programmer one ventures to the borders of philosophy all the time. But then that's one of the things I find appealing! :D

dcof

So you think that the proxy should expose a few values like the return code so that I can use it correct?

dojohansen

I'm not sure what you mean by that. It should "expose" the return value *as* a return value. Externally, it's useage should be identical to your original proxy, but internally it should call the proxy, update tracking information, and return whatever the proxy returned. Perhaps we are talking past one another. What I mean is you have some generated proxy like this:

class Proxy
{
public int Foo()
{
// ...
}
}

and some code that uses it,

class UserCode
{
void Bar()
{
var x = new Proxy().Foo();
}
}

You can now introduce a "metaproxy",

class MetaProxy
{
int clientID;
Proxy proxy = new Proxy();

public MetaProxy(int clientID)
{
    this.clientID = clientID;
}

public int Foo()
{
    var x = proxy.Foo();
    Tracking.Register("Foo", clientID, x);
    return x;
}

}

Lastly of course the user code must be modified to use MetaProxy instead of Proxy. I don't know the details of what sort of tracking you really need to do. Nor do I know, or want to know :), everything needed to say if this is how you should obtain the information you need (examplified by "clientID"). If you have this information everywhere you are making such calls, perhaps this is a good way of doing it. If you don't, and this is in an application processing requests (so that everything that happens in a thread happens on behalf of a particular client) perhaps it'd be nice to put the clientID in a ThreadStatic instead, and then your MetaProxy could just have a default constructor and sniff out the clientID from there. So you still have to do your own thinking. But hopefully this will make it clear how I propose you can establish tracking. Of course just keeping track of things is not going to do anything more than that.