Returning Business Object from Web Service

Question

Picture, if you will, the following scenario:

• BusinessObjects.dll contains a class "BusinessObject"
• WinClient references BusinessObjects.dll
• Web Service references BusinessObjects.dll

Web Service has a method:

public BusinessObject GetBusinessObject()
{
  BusinessObject result = new BusinessObject;
  result.Name = "MyBusinessObject";
  return result;
}

This method is called by the WinClient.

When I add the reference to WebService, then a proxy class will be created. So if I access BusinessObject from WinClient like so:

BusinessObject bObj = service.GetBusinessObject();

then bObj is NOT the same object in BusinessObject.dll, but is actually the proxy.

There is a work-around as documented here - http://ryanfarley.com/blog/archive/2004/05/26/737.aspx

My question - is this a good idea? Or should objects returned from a service ALWAYS be treated as simple DTOs? So if we want the logic then we should copy the values into the REAL businessObject. But what about the performance hit on doing this - should I worry about it?

Any feedback welcome, thanks.

Answer 1

Yes, always use a DTO or something like it.

The performance hit of copying data around in memory is likely to be trivial compared to the performance of the network the data is about to traverse.

Answer 2

It depends on whether the "purity" of the service is important. If the only client is going to be your exe, then I wouldn't get stressed; you can then get an "intelligent" (if you see what I mean) object at the client (for example, implementing IDataErrorInfo for validation), without any code duplication.

But if you need to support ad-hoc clients, you should stick to basic DTOs (proxy objects).

Note that if you want to go this route (assembly sharing), then you can do this in WCF without any changes; svcutil and the IDE offer options to re-use types from existing assemblies, although actually you don't even need this (you can access a channel directly). All you need is the right config data in the app.config, so it knows where to find the service.