Traditionally when we develop OO software, we can define base class in API and call that API by passing subclass object. The benefit of this design is that we can use a single API to process multiple subclasses, which is easy and reasonable.
How about the API for Web Service method then? Can we follow the same style (ie. passing subclass object to the API) to define base class in API?
Unfortunately, no!
For example: There is a web method HelloWorld() like below
public class BaseClass
{
public string Name = "Base Class";
}
public class SubClass : BaseClass
{
public string Type = "Sub class";
}
[WebMethod]
public string HelloWorld(BaseClass oClass)
{
return "Hello " + oClass.Name;
}
1. If client gets web service definition through WSDL, it cannot get definition of SubClass. So it has no way to create a SubClass object to call HelloWorld()
2. If client shares BaseClass and SubClass library with web service, then the client can create a SubClass object (oSubClass). But the client can not call HelloWorld(oSubClass) that generated by WSDL either, because WSDL does not have any information for SubClass, not to mention the relationship between SubClass and BaseClass
3. If client shares BaseClass and SubClass library with web service, and call System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke() directly:
Invoke("HelloClass", new object[] {oSubClass});
That still can not work: XmlSerializer will throw exception because we are passing an incompatible object.
So when we design the interface of web service, we have to define APIs separately for each kind of subclass!
0 comments:
Post a Comment