Well, if you are really committed to XML serialization, you can implement IXmlSerializable. Big flashing, honking warning though - it is undocumented and unsupported by Microsoft, so you could have the rug pulled out from underneath you in dotnetfx 2.0 (possible, but since DataSets use it, I'd be quite suprised if it got yanked).
Aaron Skonnard's article on this very topic: http://msdn.microsoft.com/msdnmag/issues/03/06/XMLFiles/default.aspx A tutorial on implementing IXmlSerializable in my blog: http://hoppersoft.com/Andy/PermaLink.aspx/e86b447e-aa95-49b6-909f-cda36acf481f -Andy Hopper ----- Original Message ----- From: "Daniel Ferrell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 30, 2003 4:43 PM Subject: [ADVANCED-DOTNET] Encapsulation and Serialization > We're currently working on building framework components for an enterprise > (read many users with lots of throughput) application. Part of the > framework requires a conversion from business data objects implemented in > C# to a specific format of xml and back to C# objects. > > We originally looked at XMLSerialization, however we didn't want to break > the OO tenet of encapsulation by making all of the fields public, which XML > serialization requires. We then looked at using SOAP Serialization and > transforming the SOAP formatted xml to the xml that we needed. The SOAP > solution required complex transforms and proved to create large documents > that were sometimes slow to transform. We are now back to XML > Serialization, however we are looking for a method to maintain > encapsulation. > > Does anyone have a recommendation for either of (or which would be better): > 1) Maintaining encapsulation while using the XML Serialization. > 2) Building a custom serialization mechanism that maintains encapsulation. > > Thanks, > Dan Ferrell
