.NET XML Serialization Question

.NET XML Serialization Question

• Commander Z

  Thank you again Shannon.

  As it is xml I desire for frontend manipulation the system serialization would be far from ideal. Also writing my own xml serializer would also be far from ideal as future developers will be extending my API - I would not like them to have to write custom serializers.

  Your last point is a good one and may just be the key to what I want...

  Warmest regards from sunny Scotland :-)

  Iain

  
  

• Fentonjm

  I'm trying to accomplish the same thing and found your statement very interesting:

  "Separate your business logic from your type serialization, supply the get accessor in the business logic implementation and create a data storage type that has both accessors and is only consumed by your business logic implemetnation...."

  Can you give a simple example in VB how it can be done

  I would be very grateful! Thanks!

  
  

• Gareth Ch

  Thanks Shannon. That explains the nullable aspect of the question.

  I don't like the idea of marking my properties with a setter if my business logic dictates they are read only though (take the example of a last modified date set by a trigger in the database which we would want the user to see but not be able to change in frontend).

  I can see why the mechanism expects them properties to have a setter as deserialization would be a big problem without one.

  This seems to me to be a limitation of the serialization mechanism. It effectively requires one to mark properties as public and read/write if they are to appear in the output of the serializer.

  Is there no way they could have provided an attribute which says serialize this but don't deserialize and allowed read only properties

  Is there any way then of preventing client API users from setting certain properties even if they're public and writable I can't throw an exception otherwise the deserializer would throw one.

  Cheers

  Iain

  
  

• Daniel Svensson

  You can control whether the XmlSerializer serializes a null or empty property by using the XmlElementAttribute and setting the IsNullable property to true. This will cause the property to render whether it has a value or not. You must have a setter and getter for every property you want to serialize.

  Here is an example:

  [XmlElementAttribute( IsNullable=true)]
  public string FirstName
  {
  get { return _FirstName; }
  set { _FirstName = value; }
  }

  
  

• Triforce

  It may be a limitation, but I am not sure you are using it in the typical use case (for example the framework uses it in web services for serializing types, that will become messages). There are two serialization stacks, System.Xml.Serialization and System.Runtime.Serialization.

  I typically use the System.Xml.Serialization stack for messaging (web services) and persisting/reading configuration data (keeping the business logic for validating the data in another class). The advantages of this stack are:

  n Human readable

  n Only serializes public state

  n Limited custom serialization through attributes

  n Cross platform friendly (because of xml)

  n Performance Considerations (Xml)

  System.Runtime.Serialization can serialize/deserialize properties with out having both get and set accessors. However, you will also be bound to the CLR for both serializing and deserializing... which may not be a big deal if you are just using it internally in your application. Some things to keep in mind with the Runtime.Serialization stack:

  • Not human readable (SoapFormatter is, but not easily)
  • Must have CLR on both ends
  • Will serialize both public/private state
  • Supports the concept of formatters for custom serialization
  • Highly customizable for formatting output

  So these are your options if you decide to use the System.Xml.Serialization namespace, and accomplish getting around the problem you are having:
  
  Implement the IXmlSeriailizable interface and handle your own serialization.

  Write an XmlSerializer that uses reflection to deserialize/serialize private data (that is essentially what you want to do if you are only exposing a read-only property)

  Separate your business logic from your type serialization, supply the get accessor in the business logic implementation and create a data storage type that has both accessors and is only consumed by your business logic implemetnation....

  
  

• Joakim Wingard

  Unfortunately I don't have any examples in VB... but here is what you can do.

  A pattern similar to this is exposed in the Enterprise Library Application Updater Block v2.0. You can download it at:

  http://www.microsoft.com/downloads/details.aspx FamilyId=C6C09314-E222-4AF2-9395-1E0BD7060786&displaylang=en

  you will also need the June 2005 version of Enterprise Library found here:

  http://www.microsoft.com/downloads/details.aspx FamilyId=A7D2A109-660E-444E-945A-6B32AF1581B3&displaylang=en

  After you install it, open up the solution for the VB.NET Updater solution. Look in the updater project of the solution, under the Manifest folder... there is a Manifest.vb file which has a bunch of business logic that is specific to a deployment manifest. If you look under the Xsd folder there is another Manifest.vb... this one is generated by the xsd.exe and is to be used for serialization. Look back in the Manifest\Manifest.vb file, it uses containment of the to expose the Xsd\Manifest.vb (what I called a data storage type). This is basically what I am talking about.... use one type as the data structure and then use containment to expose the data. It may seem like more work... but in the end you have more options of how to handle things like versioning of the serialized data.

  Sorry about the around about way of demonstrating this... but this should give you a better example in context then I could throw together.

  
  
• .NET XML Serialization Question