You are stuck with having a default constructor and setters on all of your properties. This is simply due to the way XML serialization works. Binary serialization works differently because it doesn't need to represent the object in a "good" format. It literally reflects all fields and spits them into a stream. XML serialization is forced to work differently due to the fact that it doesn't recreate the internal structure of an object, but rather the "external" structure, forcing you to create setters and public default constructors.
I've taken two separate approaches to this. First off, realize that web services are a document-based communication mechanism. As much as you want to imagine your objects being magically transformed to XML and back to your objects again, what is really going on is your objects are converted into an XML document that can be sent to clients that can receive XML documents. Regardless of technologies, you still have a document as a transport mechanism. That said, it does make sense to have a special facade on top of your domain objects to represent them in a document-based form. While this can be a real PITA, it's not a terrible design decision since you keep your privates private and your publics public. The only downside is that now you have two representations of your objects, the good ones and the document-friendly ones (although, that's not too different from using a relational database and manually mapping data in it to objects). All that said, I've created webservice facades for some applications that force the document-like structure. Since the moment your data leaves your webserver, all of your "live connections" back to their original sources don't matter. Your clients communicate back to you through the webservice again, so why would you actually need the original objects? On the other hand, you can also provide a manual "mapping" back from these document-friendly objects into your better-looking domain objects, and wrap the webservice client with a custom client of your own (again, not very different from what I'd bet you already do with your data source). The other thing I've done is simply deal with it. The design of my application meant I (or someone else internal) had control over how the objects are used internally, and there was no way someone could actually insert some bad data and hand the objects back to me, so it simply didn't matter that I had setters and default constructors. Adam.. -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Bill Bassler Sent: Thursday, November 18, 2004 8:44 AM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] XML public property and constructor serialization issues. 1. Can I do anything (like an xml attribute to mark the class with?) about the requirement for the serialized classes to expose a default public constructor? I'd prefer not to change my existing class design to accomodate xml serialization for exposure via the web service. 2. Can I do anything about the seeming requirement to implement both a get and set method on a public property. (like an xml attribute to mark the property with?) I'd prefer not to accessibility my existing class properties design to accomodate xml serialization for exposure via the web service. 3. I assume that pushing the existing object's data into an xml serialization/web service specific object before is a bad idea. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with C# November 29 - December 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
