3

I use a WCF service and wonder if I can use the OperationContract methods for the caller and for the service. Therefore I'd like to know the best way to say if the code is running in the application or in the service.

Like this:

[ServiceContract]
public interface IService
{
    [OperationContract]
    bool ServiceMethod(string param);
}

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single,
InstanceContextMode = InstanceContextMode.Single, UseSynchronizationContext=false)]
public class Service : IService
{
    bool ServiceMethod(string param)
    {
      if(!isInWcfService) //How to do this?
      {
        //Call this ServiceMethod in WCF Service
      }
      else
      {
        //Do the work
      }
    }
  }

Since the calling program and the service knows this class, I think it might be easier if both just have to call this one method and it decides itself if it has to forward the call to the service or can just do to work.

Thank you!

  • 2
    I'm not sure what you're proposing is a great idea. Do you want different behavior depending on whether the caller is the WCF service or not? If so, I'd suggest creating two methods which separates your logic. Having a method which can have different side effects is normally a bad design choice. – timothyclifford Jul 13 '15 at 12:08
  • well, generally the method still does one thing, just if the caller is not the wcf service, the method calls the service first which then does the intended work. My thoughts behind this were, that the assembly will be easier to use for somebody else if he just have to call this one method with the self speaking name and doesn't have to look which is for him and which for the service. An other idea is to make those classes internal and visible to two friendly assemblies, one of them is the service and the other is a assembly for the application. What do you think about that? –  Jul 13 '15 at 12:12
  • I agree with @timothyclifford. But you can use some workarounds to identify the caller of your method. One of them is to add a custom header, so if any client from WCF add this header, it can be identified easily. This example can help you: http://stackoverflow.com/a/3277754 – Ricardo Pontual Jul 13 '15 at 12:17
  • Doesn't sound like a good software design approach. You can inherit the class on the client side and override you method to add the required service service call first. – Shai Aharoni Jul 13 '15 at 12:43
  • 4
    A method that contains `if (something) { do one thing } else { do another }` is a code smell. It's clearly doing two different things, so make it two methods. If the difference between those two methods is just one thing, do that, then call into a common third method that does the rest. – David Arno Jul 13 '15 at 13:42

1 Answers1

2

You can check if you are inside a WCF service by checking OperationContext.Current, which is a WCF service class comparable to HttpContext.Current in ASP.NET:

if (OperationContext.Current != null)
{
    // inside WCF
}
else
{
    // not
}
Patrick Hofman
  • 153,850
  • 22
  • 249
  • 325
  • Does `OperationContext.Current` flow if you have passed and awaited on a `.ConfgureAwait(false)` earlier on in the code? – Scott Chamberlain Jul 13 '15 at 14:12
  • @ScottChamberlain: I really don't know. Used it before the async/await era. Had some common code that had so save some 'session info'. All synchronous. – Patrick Hofman Jul 13 '15 at 14:13