C# 3.0 Automatic Properties

Defining properties can be very tedious. Suppose you have a class

public class UserProfile
{
    private int userrId;
    private string firstName;
    private string lastName;
 
    public int UserId
    {
        get { return this.userId; }
        set { this.userId = value; }
    }
 
    public string FirstName
    {
        get { return this.firstName; }
        set { this.firstName = value; }
    }
    
    public string LastName
    {
        get { return this.lastName; }
        set { this.lastName = value; }
    }
 
    public UserProfile() { }   
}

It might not look like a lot of code, but when you think about the steps you need to go through to write that small amount of code, it can add up.

Decide on the public property name.
Declare the appropriately named and typed backing variable.
Implement the corresponding public property.

Fortunately, C# 3.0 provides a way to simplify this. Now, we can write the class this way:

public class UserProfile
{
    public int UserId { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
 
    public UserProfile() { }
}

This is certainly much more compact and requires fewer steps. When the compiler sees this class, (according to Reflector) it translates it to:

public class UserProfile
{
    [CompilerGenerated]
    private int <UserId>k_BackingField;
    [CompilerGenerated]
    private string <FirstName>k_BackingField;
    [CompilerGenerated]
    private string <LastName>k_BackingField;
    
    public int UserId
    {
        [CompilerGenerated]
        get
        {
            return this.<UserId>k_BackingField;
        }
        [CompilerGenerated]
        set
        {
            this.<UserId>k_BackingField = value;
        }
    }
 
    public string FirstName
    {
        [CompilerGenerated]
        get
        {
            return this.<FirstName>k_BackingField;
        }
        [CompilerGenerated]
        set
        {
            this.<FirstName>k_BackingField = value;
        }
    }
            
    public int LastName
    {
        [CompilerGenerated]
        get
        {
            return this.<LastName>k_BackingField;
        }
        [CompilerGenerated]
        set
        {
            this.<LastName>k_BackingField = value;
        }
    }
 
    public UserProfile() { }           
}

There are a few things to look out for when using this syntax. The compiler forces you to declare properties with both a get and a set. You also don't get any kind of "safety" features, such as ensuring that you don't allow a null value to be assigned to a string property. If you want these more "advanced" features, you'll still need to define your property the "old school" way.

Share This Post:

posted on Wednesday, August 08, 2007 10:00 PM

Feedback

# re: C# 3.0 Automatic Properties 8/9/2007 1:47 AM Mahesh

It a really nice improvement in C# 3.0. It will save lots of time writing/editing the code.

# re: C# 3.0 Automatic Properties 8/10/2007 12:25 PM Steven Harman

This certainly would have prevented me from ever running into the accidental recursion issue I wrote about the other day. :)

# re: C# 3.0 Automatic Properties 10/4/2007 6:47 PM Tim Schreiber

Can you tell me a little more about the "pubic" access modifier that Microsoft introduced in C# 3.0? I can't seem to find it in the documentation.

# re: C# 3.0 Automatic Properties 10/4/2007 6:51 PM Scott

@Tim,

First of all, I think you meant "public" right? This isn't a new operator and has been in the language since C# 1.0 was released. Are you thinking of the partial keyword, possibly?

# re: C# 3.0 Automatic Properties 10/5/2007 11:27 AM Scott

@Tim,

You're right...I had a typo in the post. It's been corrected.

# re: C# 3.0 Automatic Properties 4/30/2008 12:04 AM Momin Khalil

This is a nice short hand, but as any short cut it also comes with a price. When you generate a proxy for WCF clients from classes that use this short hand, the field names on the client are suffixed with k_BackingField. If you have a field called LastName then on the WCF client it will appear as LastNamek_BackingField.

# re: C# 3.0 Automatic Properties 5/25/2008 3:16 PM Scott

@Momin, You are correct and point out a very valid scenario where using automatic properties may not be the best solution.

# re: C# 3.0 Automatic Properties 11/14/2008 8:44 AM Tom Regan

I was Googling "k_BackingField" just to see if anyone else had run into this. This just tripped me up in my first Silverlight project.

I could not understand why my Binding expression did not work. I was doing everything right! Binding="{Binding LastName}" What could be more simple?

Finally it occured to me to look at the proxy in the object browser and I noticed that *&^%#! "k_BackingField." I changed my binding expression to Binding="{Binding LastNamek__BackingField}" and of course it worked.

# re: C# 3.0 Automatic Properties 11/15/2008 9:57 PM Scott

Tom, that is one of the drawbacks of using automatic properties. The binding interfaces and also any serialization over the wire (remoting, data contracts, etc) all suffer from similar problems.

# re: C# 3.0 Automatic Properties 5/6/2009 10:05 AM berandor

if you want 'clean' attributes for your WCF generated proxies try:

using System.Runtime.Serialization;

[Serializable]
[DataContract]
public class MyClass
{
[DataMember]
public string FirstName { get; set; }

[DataMember]
public string LastName {get; set; }
}

Scott Dorman

News

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

Feedback