Method vs Property in C# - what's the difference [duplicate]

Possible Duplicate:
Properties vs Methods

In method you can type some code and in properties too. For example I have a property Name. When class name changes I would like to get some data from database and change state of my object. I can add this code to set part of my property. Other solution is to change set part to private and add method called SetName and in this method add my code.

So what is the difference? When is the point when it's not good to put some code to getter / setter and when to create own method that is used to change my property and other parts of my class?

Here is a good set of guidelines for when to use properties vs methods from Bill Wagner (fixed link)

• Use a Property when all these are true: The getters should be simple and thus unlikely to throw exceptions. Note that this implies no network (or database) access. Either might fail, and therefore would throw an exception.
• They should not have dependencies on each other. Note that this would include setting one property and having it affect another. (For example, setting the FirstName property would affect a read-only FullName property that composed the first name + last name properties implies such a dependency )
• They should be settable in any order
• The getter does not have an observable side effect Note this guideline doesn't preclude some forms of lazy evaluation in a property.
• The method must always return immediately. (Note that this precludes a property that makes a database access call, web service call, or other similar operation).
• Use a method if the member returns an array.
• Repeated calls to the getter (without intervening code) should return the same value.

• Repeated calls to the setter (with the same value) should yield no difference from a single call.

• The get should not return a reference to internal data structures (See item 23). A method could return a deep copy, and could avoid this issue.

Given a property like this

private string _name;
public string Name { get { return _name; } set { _name = value; } }

it is possible to write the following two methods:

public string get_Name() { return _name; }
public void set_Name(string value) { _name = value; }

which act identically. And in fact, this is exactly what the compiler does for you when you create a property.

Generally speaking, I steer away from properties when the code within them starts to feel "expensive", if that makes any sense. I want properties to feel like fields (with controlled side effects that happen at specific times), so they should be lightweight.

A property is nothing but some syntactic sugar. In some cases, it is better to define a property instead of a method because it is clearer / more readable.

Design guidelines state that, when the functionality you're implementing is expensive, a method should be preferred over a property.

in fact, a property is implemented as one or two methods; depending whether your property has a setter or not. The property is translated into a get_xxx and a set_xxx method.

Coming to think of it, Properties are more than just syntactic sugar. They are the public face of your member data to you member code.

Thus, giving you a clean layer for retrieval or input of a single aspect of you member data from you code.

A DTO for example is nothing but a bunch of well written properties, cleaving data and behavior efficiently. Without a DTO would you imagine tightly coupling your DataGrid or Dropdown to complex business logic method?

Put it simply, Methods are actually doing the work...Properties either instigate action or get the status.

Though, you can use method code inside your properties ...it is not what they are meant for. Even, if you have to you are better of making a clean call to another method inside the property instead of actually writing you code in it. HTH!

Whenever I've come across the need to put code in a getter/setter I put the code in a private method and call that method from within the getter/setter. That way the code is available in a method call should I need it elsewhere. Not sure if this is the answer you were seeking but it is just a methodology I use.