Do I need to use { get; set; } with c# fields that have no special actions when getting and setting

Question

I have been coding classes like this:

public class ReportViewModel
    {
        public string Status;
        public string DataSource;
        public String DataStore { get; set; }
        public PageMeta PageMeta { get; set; }
        public ICollection<Question> List { get; set; } 
    }

Note that most of the fields use { get; set; } except the first two which I let Visual Studio add for me.

What I am wondering is do I really need to use { get; set; }. It seems to me that VS2010 does not automatically add this so do I need it?

Possible duplicate of [What is the difference between `Fields` and `Properties` in C#?](http://stackoverflow.com/questions/4446929/what-is-the-difference-between-fields-and-properties-in-c) — Frédéric Hamidi, Nov 01 '11 at 14:01
@FrédéricHamidi - worth linking to, but I think this asker is coming at that problem from a different direction, and as such this adds value as a separate question. — Keith, Nov 01 '11 at 14:09
possible duplicate of [Difference between Property and Field in C# .NET 3.5+](http://stackoverflow.com/questions/653536/difference-between-property-and-field-in-c-sharp-net-3-5) — nawfal, Jun 03 '13 at 17:01

score 6 · Answer 1 · answered Nov 01 '11 at 14:02

6

You've created a class with two public fields (Status and DataSource) and three public properties (DataStore, PageMeta and List). I would advise against having public fields - and you should actually consider whether you really need all of these to be mutable properties at all.

There are various advantages to using properties over public fields, but the main one in my mind is that a property is logically part of the API of a class, whereas a field is logically an implementation detail. The property says what callers can do - a field says how a value is stored.

answered Nov 01 '11 at 14:02

Jon Skeet

1,421,763
867
9,128
9,194

If you have really "dumb" properties like in this case with public get and set, is there a drawback in using public fields instead of properties? – Tomas Jansson Nov 01 '11 at 14:06
4

@TomasJansson: Did you read the page I linked to in my answer? – Jon Skeet Nov 01 '11 at 14:10
Missed that it was a link, but I've read it now. Great description! – Tomas Jansson Nov 01 '11 at 15:01

score 2 · Answer 2 · answered Nov 01 '11 at 14:01

2

If you want them properly exposed as properties, yes.

answered Nov 01 '11 at 14:01

canon

40,609
10
73
97

score 2 · Accepted Answer · answered Nov 01 '11 at 14:02

2

{ get; set; } indicate autoimplemented properties. In .NET there is a difference between properties and fields. Normally fields should be private. They are used for some specific implementation and should in most cases be internal to the class. Properties on the other hand are used to encapsulate behavior that is exposed to the consumers.

answered Nov 01 '11 at 14:02

Darin Dimitrov

1,023,142
271
3,287
2,928

Hello Darin, Being that these are used in a MVC3 viewmodel and that they are "dumb" with no logic required do you think it makes much difference to just have them as fields? – Samantha J T Star Nov 01 '11 at 14:24
@SamanthaJ, now that you bring the topic about ASP.NET MVC, you should always use properties in your view model. The default model binder cannot bind to fields. – Darin Dimitrov Nov 01 '11 at 14:26
Can you explain what you mean by the default model binder. I have the following working: ViewModel file: public class ReportViewModel { public string Status; etc etc... CSHTML file: @model xxx.ReportViewModel
@Model.Status
– Samantha J T Star Nov 01 '11 at 14:29
@SamanthaJ, in ASP.NET MVC the default model binder is responsible for binding view model's properties that your actions take as arguments from request values. So for example if you have the following controller action `public ActionResult Foo(MyViewModel model) { ... }`, and you send a request like `/home/foo?prop1=value1&prop2=value2`, the default model binder will automatically assign the corresponding properties of the view model from the request values. But it has to be public properties. – Darin Dimitrov Nov 01 '11 at 14:34

score 1 · Answer 4 · answered Nov 01 '11 at 14:01

1

They are different: your first two members are fields - not properties. The others are properties with auto-implemented accessors.

answered Nov 01 '11 at 14:01

Nick Butler

24,045
4
49
70

score 1 · Answer 5 · answered Nov 01 '11 at 14:04

1

When you don't add the get and set you are using a field rather than a property. Which in many cases won't make a lot of difference. However, you can't databind to a field like you can with a Property. So you would lose that.

answered Nov 01 '11 at 14:04

Jay

5,897
1
25
28

Joshua Rodgers · Answer 6 · 2011-11-01T14:14:34.760

There is a difference. The first two are fields and the remainder are auto-properties.

The second one, the compiler generates a private backing field and some boiler-plate get/set methods. These then allow you to access the properties like they were fields, but with the advantages only available to properties.

It is always recommended to hide fields behind properties, by either making them private and writing your own property around it or using an auto-property.

There's some advantages to properties. One being that properties can be made read-only, or even write-only, or read-only with an internal write-only, etc. Since they act just like methods, you can execute any arbitrary code inside of them. This is useful for when you need to implement things like INotifyPropertyChanged or if the property is actually calculated from several fields behind it.

The other advantage is encapsulation. You aren't tying yourself directly to the fields of the class, but rather the property. So if some detail about the field changes (say it goes away and becomes calculated), by using the property you are insulating yourself from those implementation details.

You should certainly look at using properties (for now adding the { get; set; }) for all cases. They are good practice in that they provide a level of encapsulation that shields the user from implementation specific details.

score 1 · Answer 7 · answered Nov 01 '11 at 14:07

At all depends on how this class will be used.

If this is in your code, just used in your current product, then there isn't really much difference between fields (no {get;set;}) and properties (with the {get;set;}).

However in that case they probably shouldn't be public, make them internal or private instead so that it's clear that external code shouldn't use them.

If your class is going to be used by other assemblies then you should always convert public fields to properties.

The reason is that if you want to extend properties later on (i.e. add a body to the set) then your users can just get the new DLL from you. However if you've used fields then converting them to a property will look the same in the IDE, but require your users to recompile when they get the altered DLL.

Being public tells consumers that they can rely on that member being present, being a property gives you more control of how you deliver it to them.

score 0 · Answer 8 · edited May 23 '17 at 12:19

0

You do not have to, but this just coding stundart, with its pros and cons. Consider this link for more resources:

Property Acessors

edited May 23 '17 at 12:19

Community

1
1

answered Nov 01 '11 at 14:03

Tigran

61,654
8
86
123

Do I need to use { get; set; } with c# fields that have no special actions when getting and setting

8 Answers8

Linked

Related