Difference between Automatic Properties and public field in C# 3.0

Question

I failed to understand why auto implemented property language feature exist in C# 3.0.

What the difference it is making when you say

public string Fi         


        

Answer 1

The first is a public field, while the second is a public property.

The main difference is in how they are used. For example WPF can only data bind to properties, not fields.

Answer 2

Just to add to what other people have said, declaring a public field, the field is accessible for read and write. declaring public automatic property, although the property is public, you can still add modifier to control the accessibility at the get/set level.

public string FirstName { get; private set; }

The user of your class sees FirstName as public property. However, he/she cannot write to it.

Answer 3

because of this use:
public string FirstName { get; private set; }
easy property, that 'kosher' by OO rules

Answer 4

Consider what happens if you later want to change each of them to a property with a custom implementation. If it's an automatically implemented property, you just add a field and change the implementation. Full source and binary compatibility.

If it's a field to start with, you get neither source nor binary compatibility. You have to rebuild everything that references it, and fix up anything which no longer compiles.

Additionally, properties have various benefits over fields. My main personal objection to fields is that it exposes an implementation decision in the API.

Answer 5

Auto properties are Compiler generated regular properties, they use a backing fields like any regular property but you don't need to write the code for that. Here is a very illustrative sample (thanks to Reflector) of the code generated by the compiler:

[CompilerGenerated]
private string <ContentType>k__BackingField;

public string ContentType
{
    [CompilerGenerated]
    get
    {
        return this.<ContentType>k__BackingField;
    }
    [CompilerGenerated]
    set
    {
        this.<ContentType>k__BackingField = value;
    }
}

Answer 6

The difference is that other assemblies compiled with code that read the property is compiled against a property.

If you later on decide you need to add code to the getter or setter, you can do that, without having to force every other assembly linked to it to recompile.

Not so with fields. If you later on change a field to be a property, in order to add that code, other assemblies linked against yours will cease to function properly since they're compiled to read a field, not a property.

Also, lots of code is written to find properties, not fields, like data binding and similar.