And if you control both ends of the wire (both are using .Net), why aren't you using Remoting. It is faster, and better, as long as you still don't send business objects over the wire.
Here is a great thread on this exact topic (from the forums): http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=90536&SiteID=1 with explainations from myself, Steve Maine, and Eugene Osovetsky. ------------------------------------------------ For the folks that have to use Web Services, and need justification on why you need to separate classes for you business object and your message object here is my comment: But if you still need other reasons, you might want to check out this post by Matt Berther, "Web service and custom serialization" http://www.mattberther.com/2006/05/000755.html. In that post, Matt is trying hard not to have " two copies of the objects", one for XML serialization and one for the business entity. My response was: 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. -------------------------------------------------------------------------------- What is cool about the above rant is that you can also use it for the whole business object verses dataset debate. Once you get beyond simple relational data validation, datasets beign to smell, and you eed to start to think about using business objects. The problem is that most developers are not familiar with creating business objects, and do not know when they are entering the smell zone (when things start to smell funny). Don Demsak www.donxml.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
