Fields vs. Properties and XMLSerializers (101)

Question

So I've been studying the use of various Serializers in the .NET Framework and while trying to experiment on preventing certain objects in a class from being serialized I was thrusted back to some very basic programming questions that I "thought" I knew. Given this example:

public class Example
{
   public string examName;
   [XmlIgnore]
   public int exampleNumber;

   public Example()
   { }
   [XmlIgnore]
   public int ExampleNumberTwo { get; set; }
}

I can create an instance of this class and using the XMLSerializer can output the content of this class in XML format. The [XmlIgnore] attribute actually does what I'd expected; it prevents the serialization of the referenced items.

So venturing further I replaced the [XmlIgnore] declaration for "exampleNumber" with [NonSerializable] expecting the similar results but the output did not change. After searching through resources, it was stated that the [NonSerializable] attribute should only be used on fields and [XmlIgnore] attributes should be used on properties.

Yet another post stated that the [NonSerializable] attribute has no effect when using the XMLSerializer but will produce the expected results when using the SOAP or BinaryFormatter. So I'm lost on the concept at this point.

But this brought me to the basic question, what defines a field vs. a property? I know its a basic question and I've even viewed other discussions here but the degree of clarity I am looking for still wasn't really clear.

I can use the [XmlIgnore] attribute on the property (ExampleNumberTwo) or the variable (exampleNumber) so the statement that it can ONLY be used on Properties doesn't seem correct.

But then again, I have always referred to the objects in my example such as (examName) and (exampleNumber) as being member variables. So what exactly is the signature of a "Field"

Can anyone shed some light on this?

dlev · Accepted Answer · 2011-08-19T14:27:01.607

The MSDN documentation supports the idea that [NonSerialized] only gives the expected results with the binary and SOAP serializers:

When using the BinaryFormatter or SoapFormatter classes to serialize an object, use the NonSerializedAttribute attribute to prevent a field from being serialized. For example, you can use this attribute to prevent the serialization of sensitive data.

The target objects for the NonSerializedAttribute attribute are public and private fields of a serializable class. By default, classes are not serializable unless they are marked with SerializableAttribute. During the serialization process all the public and private fields of a class are serialized by default. Fields marked with NonSerializedAttribute are excluded during serialization. If you are using the XmlSerializer class to serialize an object, use the XmlIgnoreAttribute class to get the same functionality. Alternatively, implement the ISerializable interface to explicitly control the serialization process. Note that classes that implement ISerializable must still be marked with SerializableAttribute.

In terms of "field" vs. "property", fields are straight data variables contained by a class. Properties are actually specially named methods on the class (get_PropName() and set_PropName()). In your code, the compiler allows you to use properties the same way you would use a field, and then inserts the appropriate get/set call for you.

Oftentimes, properties will be simple wrappers around a field:

private int myField;
public int MyProperty
{
    get { return myField; }
    set { myField = value; }
}

But they don't have to be:

public int TodaysDate
{
    get { return DateTime.Today; }
}

In general, you want all your fields to be private, since they're supposed to be implementation details. Any simple data that you'd like to expose should be done via a property, since you can easily surround the data access with (changeable) logic.

Ok, so the type of Formatter being used definitely makes a difference as well. That was a bit confusing to me having received 2 different explanations and not understanding how those explanations were somehow related. But your post makes it abundantly clear now. — Mark, Aug 19 '11 at 14:14
@Mark glad to help. It's definitely consfusing when you have different sources saying different things. — dlev, Aug 19 '11 at 14:16
Also, thanks for the additional clarification. I was always taught and referred to the fields as private or public member variables and so never really consciously regarded them as "fields". This is a good refresher on getting back to the basics. I get so consumed in coding that I often take for granted the appropriate terminology, I just know what it does and how to use it. Bad habit though. Thx! — Mark, Aug 19 '11 at 14:25

score 2 · Answer 2 · answered Aug 19 '11 at 14:02

2

In C#, the short answer is that properties have get and/or set methods, while fields do not. VB.NET makes it a little more evident by requiring the "Property" qualifier to be used to differentiate one.

With C#, you can just append " { get; set; }" to the end of a field's definition and it's now a property.

Where this really comes into play is in reflection. Fields and Properties are segregated from one another into different enumerable collections.

answered Aug 19 '11 at 14:02

Wesley Long

1,708
10
20

Ok, this is a good way to remember the basic differences. I never considered it like that. – Mark Aug 19 '11 at 14:18

score 1 · Answer 3 · edited May 23 '17 at 12:26

1

This answer to What are the differences between the XmlSerializer and BinaryFormatter will help you get started in the right direction.

edited May 23 '17 at 12:26

Community

1
1

answered Aug 19 '11 at 14:01

SwDevMan81

48,814
22
151
184

1

Great reference link SwDevMan81! It most definitely sheds light on what takes place under the hood. I believe I'll print it for my own personal reference. – Mark Aug 19 '11 at 14:19

Fields vs. Properties and XMLSerializers (101)

3 Answers3