Accessors behavior in c# is doubtful

Question

Is the declaration

public string FirstName;

equivalent to

public string FirstName { get; set;}

I believe there is no difference, but I found the following: when I created a model - something like this

public class Subject
{
    public string SubjectName;// { get; set; }
}

and then posted this object using form in MVC, I get SubjectName value null. But if I remove commented accessors then I get a value. Is there any reason for such behavior?

@大师燈XiHuan possibly but this seems to be more as to how Fields and Properties relate to MVC — David Pilkington, Nov 07 '13 at 07:53
@BSoD_ZA Since the OP asked *Is below code is equivalent...I believe there is no difference, but...* I think this questions implies *What's the difference between these two code variants*. Also, the OP knows already that fields will not work when using the MVC framework, only properties. — sloth, Nov 07 '13 at 08:01
@xi-huan i just want to know why fields don't work in MVC and Wpf apps. what is special in Properties. — A.T., Nov 07 '13 at 08:03

Sergey Berezovskiy · Answer 1 · 2013-11-07T07:58:17.643

5

It's not equivalent code. There is big difference - without accessors you have public field, with accessors you have auto-implemented property. MVC, WPF, Entitiy Framework etc needs properties (in MVC default model binder works only with properties). See Properties vs Fields – Why Does it Matter?

edited Nov 07 '13 at 07:58

answered Nov 07 '13 at 07:51

Sergey Berezovskiy

232,247
41
429
459

Jonathon Reinhart · Accepted Answer · 2013-11-07T07:58:36.387

These two are certainly not equivalent.

public string FirstName;

public string FirstName { get; set; }

The first is a typical field, just like a plain-old C++ class member.

The second is a property. More specifically it is an auto-implemented property. Properties are essentially just syntactic sugar for _get() and _set(value) functions, like one would be used to in Java. Auto-implemented properties take it a step further and hide the backing field where the data is saved for you.

Since you're supposed to use properties, and not fields, for your public API, many .NET frameworks/APIs like MVC, EF, etc. will do special things with the properties of a class (for example automatically create a database schema).

Why are you supposed to use properties? Consider the following example. You have a plain-jane class, with an auto-implemented property.

public class Foo {
    public int Bar { get; set; }
}

And you have some client code:

var f = Foo();
f.Bar = 32;

Let's say you want to add an event that fires when you change something in Foo. Since you used a property, you can simply change the implementation:

public class Foo {
    private int m_bar;
    public int Bar {
        get { return m_bar; }
        set {
            m_bar = value;
            OnChanged();
        }
    }

    public event EventHandler Changed;
    protected virtual void OnChanged() {
        var evt = Changed;
        if (evt != null)
            evt(this, EventArgs.Empty);
    }
}

and (the important part!) the client-facing API stays the same. This is just one example of how properties are definitely the "right choice".

thanks now i need to find those special things about properties :) — A.T., Nov 07 '13 at 08:05
@Arun Unfortunately I'm not terribly familiar with how MVC handles properties specially. In Entity Framework, you can use [code first](http://msdn.microsoft.com/en-us/data/jj193542.aspx) to generate your database from your objects. — Jonathon Reinhart, Nov 07 '13 at 08:06

score 1 · Answer 3 · answered Nov 07 '13 at 07:51

1

Field

public string SubjectName;

Property

public string SubjectName { get; set; }

Both are serving the same value but they are different.

answered Nov 07 '13 at 07:51

Nikson Kanti Paul

3,394
1
35
51

Accessors behavior in c# is doubtful

3 Answers3