views:

47

answers:

1

I am looking for a way to have the generated proxy class for a Web Reference (not WCF) implement a common interface in order to easily switch between web service access and "direct" access to our business layer in the client application, something like:

public IBusiness GetBusinessObject()
{
  if (_mode = "remote")
    return new BusinessWebService.Business(); // access through web service proxy class
  else
    return new Business(); // direct access
}

However, custom types (e.g. the CustomSerializableType in the examples below) aren't referenced in the generated proxy class. Instead new, identical types are generated, which makes it impossible for the proxy class to implement the interface.

Is there some way to make the generated proxy class reference these types, or am I going about this all wrong? Should I consider converting the web service to a WCF service instead?


Details

Our solution consists of these four projects:

  • A business library (contains business logic, accesses data store)
  • A common library (contains common functionality, including the CustomSerializableType)
  • A web service (acts as a proxy between remote clients and the business layer)
  • A windows application

Our client wants the windows application to be able to run in two different modes:

  • Local mode, where the application simply uses the business library directly to access data
  • Remote mode, where the application communicates with the web service to access data

In order to do this, we have created an interface, IBusiness, which is located in the common library and contains all business methods.

Interface

public interface IBusiness
{
  CustomSerializableType DoSomeWork();
}

Business layer

public class Business : IBusiness
{
  public CustomSerializableType DoSomeWork()
  {
    // access data store
  }
}

Web service

public class WebServiceBusiness : IBusiness
{
  private Business _business = new Business();

  [WebMethod]
  public CustomSerializableType DoSomeWork()
  {
    return _business.DoSomeWork();
  }
}

Generated proxy class (a ton of code left out for readability)

public partial class Business
  : System.Web.Services.Protocols.SoapHttpClientProtocol
{

  public CustomSerializableType DoSomeWork()
  {
    // ...
  }

  public partial class CustomSerializableType {
    // PROBLEM: this new type is referenced, instead of the
    // type in the common library
  }
}
+1  A: 

Assuming that the default namespace for your client is "Client", and that your web reference is named "Proxy", then do the following;

  1. In the root of your client project, create a folder named "Proxy".
  2. In that folder, create a class named "Business".
  3. Make that class public and partial, and have it implement your IBusiness interface

This way, you do not need to modify the Reference.cs. You should never modify Reference.cs, or any other file produced through code generation.

Note that this violates the principals of SOA by tightly binding your client to your service. At the very least, you should define those interfaces in a separate project, so that you are only sharing the "interface" project between the client and service.

John Saunders
But what about the 'cloned' types that are included in Reference.cs (and in some cases exist as .datasource files under Reference.map)? These classes effectively change the method signatures so that they do not match those in the interface, thereby preventing me from implementing it in the first place. Or am I missing something here?
Bernhof
Yes, you missed something! If the proxy types don't match the interface, then they cannot implement the interface. You'll have to create your own separate set of types that _do_ implement the interface, but which then call upon the web service to do their work. This is exactly what you would do if you wanted to switch between an implementation that used a database and one that used an XML file.
John Saunders
So in order to call the web service, I need to manually convert the types referenced by the interface (e.g. `Common.CustomSerializableType`) to the (cloned) types used by the proxy class (e.g. `Proxy.CustomSerializableType`)?
Bernhof
Yes. This is one really good reason to use SOA and not tightly bind the client an the service. Better still, use WCF, which has a solution to this problem.
John Saunders
Ok, thanks. I really appreciate your help :) Where can I read about WCF's solution to this problem?
Bernhof
@Bernhof: I would start with http://stackoverflow.com/tags/wcf/info
John Saunders