一直在用 Property     但仿佛理解一直很模糊   看了玉开的C#语法糖（Csharp Syntactic sugar）大汇总   结合一些资料  汇总在一起  方便自己的理解及查找

一直都是这样定义的

01

private string _myName;

03 public string MyName
05 {
07     get { return _myName; }
09     set { _myName = value; }
11 }
也没觉得不方便   可能是习惯的原因  事实上却可以简化成这样

public string MyName { get; set; }

 

C#首选的Property构造方法


在类中预定义的一个property会提供取值和赋值访问器
下面为property版的Author访问器
class Author
{
    string firstName;
    string lastName;
    public string AuthorName
    {
        get { return firstName + " " + lastName; }
    }
}
在Sample中我只是简单定义了一下所谓的取值器，目的则是通过呈示2种不同的实现手法来解释Property这种语言构造的基本特征（也是最显著的）：
一个property的名称应与其关联attribute的名称相符，但应以大写字母开头(Pascal命名法)

一个property的类型必须与其关联的attribute类型一致

一个property定义取值和赋值访问器，但是它们的声明和客户代码调用方式都不一样。不必为取值访问器声明返回类型，不必为赋值访问器声明参数列表，它会自动取得名为value的单个参数，代表了客户代码提供的新值
实现property进步在：
整体的声明了property的类型，而访问器自动从property继承该类型
整体的声明了property的访问性，访问器自动从property继承该性质
对于公共的Attribute，除了直接赋值之外不会有其他的代码执行，而对于property访问器，我们编写的所有代码都将执行。
在某种程度上，property提供了从客户代码访问公共Attribute的方便性：某个Attribute目前很简单，但是我们无法保证以 后它不会扩展得很复杂，在扩展中我们可以通过改变property的内部逻辑来达到我们的目的而不是直接对Attribute进行操作，这带来的便捷是可 以想象的
另外，property提供了使用私有Attribute和取值/赋值控制数据的完整性。客户代码对property的操作最终作用于对象的 Attribute，例如为了防范不符合业务逻辑的客户代码的输入，我们就必须拒绝它的传入。为了达到拒绝的目的，我们大可不必另外编写验证的代码，而是 把过程放置在set赋值访问器内部