Comments on: Web service and custom serialization http://www.mattberther.com/2006/05/17/web-service-and-custom-serialization/ Agile Manager and Occasional Code Monkey Sun, 21 Feb 2010 22:01:35 +0000 http://wordpress.org/?v=2.8.5 hourly 1 By: Steve Maine http://www.mattberther.com/2006/05/17/web-service-and-custom-serialization/comment-page-1/#comment-1009 Steve Maine Sat, 20 May 2006 16:06:36 +0000 http://www.mattberther.com/blog/?p=755#comment-1009 For the record, this story gets a lot better in Indigo. The DataContractSerializer supports [Serializable], ISerializable, [DataContract] and IXmlSerializable, and you can mix and match the various serialization models within the same object graph. For the record, this story gets a lot better in Indigo. The DataContractSerializer supports [Serializable], ISerializable, [DataContract] and IXmlSerializable, and you can mix and match the various serialization models within the same object graph.

]]> By: Matt Berther http://www.mattberther.com/2006/05/17/web-service-and-custom-serialization/comment-page-1/#comment-1008 Matt Berther Thu, 18 May 2006 02:26:43 +0000 http://www.mattberther.com/blog/?p=755#comment-1008 Havagan: It wasnt necessarily that I was married to the idea of this coming back using the SOAP formatter. I just wanted to avoid having a default public constructor on my business classes. Don: As always, you make a perfectly valid argument. I think this is probably what we'll end up doing. Havagan: It wasnt necessarily that I was married to the idea of this coming back using the SOAP formatter. I just wanted to avoid having a default public constructor on my business classes.

Don: As always, you make a perfectly valid argument. I think this is probably what we’ll end up doing.

]]> By: Don Demsak http://www.mattberther.com/2006/05/17/web-service-and-custom-serialization/comment-page-1/#comment-1007 Don Demsak Thu, 18 May 2006 00:01:54 +0000 http://www.mattberther.com/blog/?p=755#comment-1007 I'd suggest that you have 2 copies of the "objects", even though you think it stinks. You have to remember that even though the "objects" have the same name, they are actually built to accomplish 2 different goals. The class that you have now, it is a business object, and thus has to conform to your business rules (which is part of the reason why you don't have a default constructor). Business classes contain the business data and the business behaviors. On the other hand, you have this representation of your business object that you wish to pass along the wire. The representation is a message, and not a business object. This class will contain a representation of the data contained within the business object, but as it is a message, it contains no business rules. Once you decouple the message from the business object, you will have an easier time distinguishing between your core business rules, and your message rehydration rules. In do so, you are also better able to handle versioning of your public facing contracts (in web services this is done via WSDL and XML Schema). You can now update and change your business objects as needed, and only add any new data to your message when that new functionality is required. By going down this path you will also be able to utilize the more enterprise friendly Web Services Contract First approach to building web services. I know that there are a lot of people that will disagree with me, and feel as you do, that by splitting things into messages and business objects, you are just adding to the bloat of a system, but I’ve learned that as long as you don’t hit the architectural issues that you discuss here, that yes, the message based methodology is overkill for your particular project. But once you start to see that there is differences between the way you want to implement the business object, and the way you want to represent it on the wire, then you need to start to think about going down the message path. A comprising between these 2 designs is to implement the IXmlSerializable interface, on your business classes, but eventually this will also become too cumbersome and you will have to go the route of the message methodology, especially when you have to handle multiple minor versions of your message coming thru the same web service. I’d suggest that you have 2 copies of the “objects”, even though you think it stinks. You have to remember that even though the “objects” have the same name, they are actually built to accomplish 2 different goals. The class that you have now, it is a business object, and thus has to conform to your business rules (which is part of the reason why you don’t have a default constructor). Business classes contain the business data and the business behaviors. On the other hand, you have this representation of your business object that you wish to pass along the wire. The representation is a message, and not a business object. This class will contain a representation of the data contained within the business object, but as it is a message, it contains no business rules.

Once you decouple the message from the business object, you will have an easier time distinguishing between your core business rules, and your message rehydration rules. In do so, you are also better able to handle versioning of your public facing contracts (in web services this is done via WSDL and XML Schema). You can now update and change your business objects as needed, and only add any new data to your message when that new functionality is required. By going down this path you will also be able to utilize the more enterprise friendly Web Services Contract First approach to building web services.

I know that there are a lot of people that will disagree with me, and feel as you do, that by splitting things into messages and business objects, you are just adding to the bloat of a system, but I’ve learned that as long as you don’t hit the architectural issues that you discuss here, that yes, the message based methodology is overkill for your particular project. But once you start to see that there is differences between the way you want to implement the business object, and the way you want to represent it on the wire, then you need to start to think about going down the message path.

A comprising between these 2 designs is to implement the IXmlSerializable interface, on your business classes, but eventually this will also become too cumbersome and you will have to go the route of the message methodology, especially when you have to handle multiple minor versions of your message coming thru the same web service.

]]> By: Havagan http://www.mattberther.com/2006/05/17/web-service-and-custom-serialization/comment-page-1/#comment-1006 Havagan Wed, 17 May 2006 21:18:30 +0000 http://www.mattberther.com/blog/?p=755#comment-1006 I rarely use XML so this is a shot in the dark... how about using the XMLTypeMapping to specificy the XML output should conform to SOAP format? <a href="http://www.topxml.com/xmlserializer/customizing_xml_serialization.asp" rel="nofollow">http://www.topxml.com/xmlserializer/customizing_xml_serialization.asp</a> <a href="http://msdn2.microsoft.com/en-us/library/system.xml.serialization.xmltypemapping.aspx" rel="nofollow">http://msdn2.microsoft.com/en-us/library/system.xml.serialization.xmltypemapping.aspx</a> I rarely use XML so this is a shot in the dark… how about using the XMLTypeMapping to specificy the XML output should conform to SOAP format?

http://www.topxml.com/xmlserializer/customizing_xml_serialization.asp
http://msdn2.microsoft.com/en-us/library/system.xml.serialization.xmltypemapping.aspx

]]>