Di una cosa simile, ne discutevo tempo fa con un paio di amici.
L'argomento citato in questo post è leggermente diverso ma il concetto è chiaro: evitare di esporre l'accesso diretto ai campi (pubblici) di un oggetto, ma incapsularlo un una proprietà.
Il motivo lo spiega Eric Gunnerson in questo post (da cui cito):
The reason that the library design guidelines suggest you write a property here is that it is important that libraries be easily versioned. If you put a property in there ahead of time, you can change the property implementation without requiring users to recompile their code.
Sebbene più avanti lo stesso Eric dice:
But, if the clients of a class are always compiled together with a class - or at least shipped together - then there is no versioning issue to consider. In that case, I think it's a bad idea to write the "trivial property" - all you've done is complicate your code without any benefit. If the public field you write needs to be a property, then just make the change and recompile
personalmente sono sempre propenso ad usare le property. Non si sa mai....un domani....
Fonte: Eric Gunnerson's C# Compendium : Properties vs public fields redux...
Tags: .Net CSharp