Yes, you should.
Properties are not related to validation. This is just the abstraction feature which allows you to present the syntax like in setting or reading a value to/from a field and hide
side effects behind such assignment ("=") syntax. Typically, a property is
backed by some underlying fields which is supposed (in a good programming style) to be private, but this is not required. However it's good to have one or another kind of assignment semantic for a property, otherwise some other features should be used.
Usually, using non-private fields is considered to be a bad style of programming. If you have some public member with assignment semantic, it should be a property. It allows for better supportability of projects: even if assignment or reading a value of some field does not require any side effect, you may need to implement it later. In this case, you can use
auto-defined properties. If later you want to add some side effect, you leave the existing property member, only add a
getter or a
setter. This way, you won't need to change any code using your property, in contrast to the situation of you had a field and later decide to promote it to a method or two method to assign and read some value.
Please see:
http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx[
^].
—SA
Submit an article or tip