You might be wondering why some classes in the .NET Framework have properties, other classes have GetXXX methods, and some have a combination of the two. The reason is that the semantic, or meaning, is quite different.
Consider this class:
public class Customer
{
public int CustomerID;
public string FirstName;
public string LastName;
public Order[] GetOrders()
{
// do database work
}
}
The CustomerID, FirstName, and LastName represent the customer state. The orders are derived from the customer state using GetOrders(). In fact I do not support having method like this because it presumes that a canonical representation of Order exists. That's another topic.
A great rule-of-thumb regarding properties is to consider that the Visual Studio debugger executes the getter method when watching an object. That is, property accessors are executed at unpredictable times and should thus not cause any discernable side-effects. Abusing properties can lead to heisenbugs.
Another reason to use a method is that order retrieval is likely to be parameterized.
Finally, a good practice is for property access to be computationally cheap; client code should not be forced to place the property value into a local variable - it's premature optimization. Expensive code should be placed in methods - client code is sure to store and reuse the result. The exception is if the property getter method caches the result in a private field, which can be a challenge as the class instance is mutated.
The property syntax in .NET languages is not syntactic sugar. It adds considerable richness to classes.