If you are just looking at the simple example, you're right, it looks like a waste.
BUT...
There is more to it.
Here is a great article that goes into much more depth: Why Properties Matter
by Stack Overflow legend Jon Skeet.
First of all, it has become a best-practices rule to not expose class fields publicly. You have no control over what happens to he value. But if you use a property instead, you have the ability to add additional logic that happens under the hood as often as needed, without ever changing anything to the public interface of your class. This could be code for handling multiple accesses to limited resources like network/ database, etc. ...
Second, with the version with the backing field you can very easily implement the INotifyPropertyChanged
interface for using the values with WPF and the Model-View-ViewModel (MVVM) pattern:
public string FavoriteColor
{
get
{
return this.favoriteColor;
}
set
{
if (value != this.favoriteColor)
{
this.favoriteColor = value;
if (this.PropertyChanged != null)
{
this.PropertyChanged(this, new PropertyChangedEventArgs("FavoriteColor"));
}
}
}
}
(Code snippet taken from Basic MVVM QuickStart)
Third: But if you would ever need to change from a public field to a property - the will get different IL code - You are loosing binary compatibility. This might affect serialization and re-compiling code from other assemblies that access the changed class. This would be bad if you are deploying your application in partial updates where not all assemblies are deployed at the same time.
On the other hand, you can implement properties both with a backing field or as auto-properties, and in both cases you will get the same IL code, which means that you have less risk to break something.