I have two experimental web services. One is an asmx contained within a .net web application. The other is a WCF service library being invoked from the web application.
The asmx basically does everything I need, but I think WCF would be better, except that it doesn’t do anything as I would expect after fiddling with the asmx service.
For example, the same method behaves differently in each:
' ASMX
<WebMethod(BufferResponse:=True, EnableSession:=False)>
Function Test(aObject as Object) as Object
' object will have been successfully serializaed into a dictionary
Dim lResult as SomeObject = new SomeObject(aObject)
return lResult ' lResult will be serialized as whatever type it is and will be deserialized by client making ajax call
End Function
' WCF
<OperationContract()>
<WebInvoke(RequestFormat:=ServiceModel.Web.WebMessageFormat.Json,
ResponseFormat:=ServiceModel.Web.WebMessageFormat.Json,
BodyStyle:=WebMessageBodyStyle.Wrapped)>
Function Test(aObject As Object) As Object
' object is serialized as an empty instance of Object
' not very useful
Dim lResult as SomeObject = new SomeObject(aObject) ' waste of time with useless object
return lResult ' even if lResult could be instantiated the client returns error 500 because
' WCF won't serialize SomeObject as Object
End Function
I’ve been researching this problem off and on for several months as I have time between projects. Nothing I’ve tried makes WCF do what ASMX does. Any ideas?
The way that I see it is that you create WCF services to a specific Interface contract.
If you can just specify any type of Object, then there is no programmatic mechanism to validate that either end of the pipe has correctly implemented that Interface.
I have found WCF to be generally much more restrictive than ASMX in terms of class serialization and deserialization, but switching to WCF from ASMX has tremendously improved our applications in terms of stability, maintainability, and productivity.
Having said that, there is no reason to switch to WCF just because it is WCF. You need to identify exactly why you think it is better for your situation and, if it is, then you need to create some test cases using actual classes instead of just Objects to verify that it will meet your needs.
One thing to think about: if you are consuming WCF services in your own .Net applications written in Silverlight, WPF, or WinForms, then WCF will make your life a lot easier in the long run because it makes it possible to share the same business object class code on both ends of the pipe.
Update with info from comments
Actually, you can serialize abstract classes as long as they can be deserialized to concrete implementations. You can do this by attributing the abstract class with the KnownType attribute for each of the concrete classes that you want to serialize.
The primary issue is not the service interface contract, it is the DataContract which requires a concrete class at some point. This link describes the rules.
You could create a catchall class that inherits from object and is decorated with known type for the classes you want to use.