Why is it good to use Properties instead of fields?

Question

I read a lot on how I am never supposed to use fields in my models and DTOS but I dont ever read why this is.

public int property{ get; set; } 

public int Foo;

under the hood that is the difference between theese two?

Answer 1

One important difference is that interfaces can have properties but not fields.

This article given by JON SKEET is very useful in understanding this.

Practical benefits of properties

There are times when you could use non-private fields, because for whatever reason you don't care about the compatibility reasons above. However, there are still benefits to using properties even for trivial situations:

• There's more fine-grained access control with properties. Need it to be publicly gettable but really only want it set with protected access? No problem (from C# 2 onwards, at least).
• Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter.
• Want to log all access? Just add logging to the getter.
• Properties are used for data binding; fields aren't.

Answer 2

One good reason is because it allows you to incluede logic and verification inside of the getters and setters

Answer 3

Taken from: http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx

Practical benefits of properties

There are times when you could use non-private fields, because for whatever reason you don't care about the compatibility reasons above. However, there are still benefits to using properties even for trivial situations:

There's more fine-grained access control with properties. Need it to be publicly gettable but really only want it set with protected access? No problem (from C# 2 onwards, at least). Want to break into the debugger whenever the value changes? Just add a breakpoint in the setter. Want to log all access? Just add logging to the getter. Properties are used for data binding; fields aren't. None of these are traditional "adding real logic" uses of properties, but all are tricky/impossible with plain fields. You could do this on an "as and when I need it" basis, but why not just be consistent to start with? It's even more of a no-brainer with the automatic properties of C# 3.

The philosophical reason for only exposing properties

For every type you write, you should consider its interface to the rest of the world (including classes within the same assembly). This is its description of what it makes available, its outward persona. Implementation shouldn't be part of that description, any more than it absolutely has to be. (That's why I prefer composition to inheritance, where the choice makes sense - inheritance generally exposes or limits possible implementations.)

A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. A field, on the other hand, communicates the implementation - it says "this type represents a value in this very specific way". There's no encapsulation, it's the bare storage format. This is part of the reason fields aren't part of interfaces - they don't belong there, as they talk about how something is achieved rather than what is achieved.

I quite agree that a lot of the time, fields could actually be used with no issues in the lifetime of the application. It's just not clear beforehand which those times are, and it still violates the design principle of not exposing implementation.