Serializing properties

[Rein Petersen]

Hi Folks!

Here's a strange behaviour:

Without a properties SET accessor (see code below), the property will not
serialize.

public class myObject
{

private string _myAttribute;

[XmlAttribute("MyAttrib")]
public string myAttribute
{
get { return _myAttribute; }
set { _myAttribute = value; } //this accessor must be present to
serialize
}

public myObject()
{
_myAttribute="set during construction...";
}

}

I would prefer the property (myAttribute) be accessible only by GET but if I
want it to serialize I must allow the SET. Is there any way around this?

Rein

 

[Nicholas Paldino [.NET/C# MVP]]

Rein,

This makes sense. XML serialization uses the accesor to the property to
set the value, it does not access the fields on the class level. If you
want to get around this, use the SoapFormatter and use regular
serialization.

Hope this helps.

 

[Tim Johnson]

Rein,

You need the set accessor if you are serialising, as you need to provide a
way to de-serialise.

You can apply the "ReadOnlyAttribute" to the property, which prevents the
user from changing the property at design time.

You could probably also have your serialized property completely hidden
(apply the Browsable, and EditorBrowsable attributes), and have another
property with just the Get which is not serialized.

Tim.

 

[Rein Petersen]

This makes sense. XML serialization uses the accesor to the property
to

set the value, it does not access the fields on the class level. If you
want to get around this, use the SoapFormatter and use regular
serialization.

Hmmm, I can't say I agree it makes sense - I'm not asking the serialization
process to SET the property, but rather to GET it and serialize it.

Is this really a sensible behaviour? Can anyone explain why this is?

Admittedly, I'm not keen on the SoapFormatter because I think SOAP sucks and
I doubt that I will be able to format the resulting serialized xml as I
require. Are there any decent resources detailing customizing the
serializing using the SoapFormatter where I can confirm this?

Rein

 

[Rein Petersen]

Thanks Tim,

Your explanation and suggestions solved my problem.

Rein

Rein,

You need the set accessor if you are serialising, as you need to provide a
way to de-serialise.

You can apply the "ReadOnlyAttribute" to the property, which prevents the
user from changing the property at design time.

You could probably also have your serialized property completely hidden
(apply the Browsable, and EditorBrowsable attributes), and have another
property with just the Get which is not serialized.

Tim.

Hi Folks!

Here's a strange behaviour:

Without a properties SET accessor (see code below), the property will not
serialize.

public class myObject
{

private string _myAttribute;

[XmlAttribute("MyAttrib")]
public string myAttribute
{
get { return _myAttribute; }
set { _myAttribute = value; } //this accessor must be present to
serialize
}

public myObject()
{
_myAttribute="set during construction...";
}

}

I would prefer the property (myAttribute) be accessible only by GET but

if

I
want it to serialize I must allow the SET. Is there any way around this?

Rein

 

[Nicholas Paldino [.NET/C# MVP]]

Rein,

It makes sense because the operation has to go two ways. If you are
able to serialize a value, then you need to be able to read the value from
the object. If you want to de-serialize an value then you need to be able
to write the value to the object. Since the XML Serializer handles both
operations, it needs to know that whatever it can read from, it can also
write to. Granted, the XML serializer could have been coded to ignore
elements that don't have a representation in the object model (and vice
versa), but I think that they wanted to get some sort of type-safety in
there.

The SoapFormatter is going to be different, in the sense that your
properties are not going to be serialized. Rather, your internal fields on
your class are going to be serialized. Now if you have a basic one-to-one
mapping between your fields and your properties, then this is ok. However,
if your properties are a composite of many values in the fields, then you
probably don't want to duplicate the business logic to calculate those
fields. In this case, a better approach would be to have a separate object
which has public read only fields which you can set through the constructor
of the object. Your object would create an instance of this object, setting
the values. Then, it would serialize that using the SoapFormatter. Your
XML will then be easier to manipulate.

 

[Rein Petersen]

Nicholas,

Thanks for the insightful distinctions between Xml Serializer and
SoapFormatter. I now understand how your suggestion to use the SoapFormatter
(ableit for an unconventional purpose), can provide flexibility in
conforming serialization to a desired schema.

If the goal of serialization is to represent a snapshot of an object's
state, then serializing it's private fields (over public properties) makes
sense.

I'm certain this is my solution.

Thanks again!

Rein

Rein,

It makes sense because the operation has to go two ways. If you are
able to serialize a value, then you need to be able to read the value from
the object. If you want to de-serialize an value then you need to be able
to write the value to the object. Since the XML Serializer handles both
operations, it needs to know that whatever it can read from, it can also
write to. Granted, the XML serializer could have been coded to ignore
elements that don't have a representation in the object model (and vice
versa), but I think that they wanted to get some sort of type-safety in
there.

The SoapFormatter is going to be different, in the sense that your
properties are not going to be serialized. Rather, your internal fields on
your class are going to be serialized. Now if you have a basic one-to-one
mapping between your fields and your properties, then this is ok. However,
if your properties are a composite of many values in the fields, then you
probably don't want to duplicate the business logic to calculate those
fields. In this case, a better approach would be to have a separate object
which has public read only fields which you can set through the constructor
of the object. Your object would create an instance of this object, setting
the values. Then, it would serialize that using the SoapFormatter. Your
XML will then be easier to manipulate.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

property

Hmmm, I can't say I agree it makes sense - I'm not asking the serialization
process to SET the property, but rather to GET it and serialize it.

Is this really a sensible behaviour? Can anyone explain why this is?

Admittedly, I'm not keen on the SoapFormatter because I think SOAP sucks and
I doubt that I will be able to format the resulting serialized xml as I
require. Are there any decent resources detailing customizing the
serializing using the SoapFormatter where I can confirm this?

Rein