Did you consider just writing your own formatter (implement IFormatter) to use reflection to perform the object <-> xml transformations exactly to your liking? This would allow you to maintain whatever OO-style encapsulation you already have while still localizing the object/xml conversion in one spot generically (the formatter). If you wanted to allow object developers to tune/tweak how your formatter generated any of the output, you could provide custom attributes to be used in the same manner as with xml serialization.
-Mike DevelopMentor http://staff.develop.com/woodring > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of > Daniel Ferrell > Sent: Friday, May 30, 2003 2:43 PM > To: [EMAIL PROTECTED] > > 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 >
