The issue is encapsulation.
Data protection and encapsulation is a standard OOP principle. The issue here isn't whether you
can, it's whether you
should. By using an automatic property, you're creating a "stub" whereby you can add logic, if you need to.
Also, using public fields can wreak havoc on other things.... for example, what if you were to use reflection on your class (where you get and set properties based on metadata) and you had previously used a field? Well, you'd have to change that code.
Also, you can't databind to a field. You have to data bind to a property.
There's several posts out there on the internet, some that would argue for the use of fields over properties, and several that would argue the other way around.
Personally, I think it's worth using properties simply to stick to convention. The convention is to wrap a private field in a public property. Everyone understands that, so I should stick to it to avoid confusing people.
Performance-wise, simple properties do the exact same thing as public fields, as the call is optimized out by the JIT compiler.
I'd stick to the convention.
Coding Light - Illuminated Ideas and Algorithms in SoftwareCoding Light Wiki �
LinkedIn �
ForumsBrowser