如果您有一个获取并设置为实例变量的Property，那么通常您总是使用该类外部的Property来访问它。
我的问题是，你是否也应该在课堂上一直这样做？我一直在使用Property（如果有的话），即使在类中也是如此，但我希望听到一些支持和反对哪一个是最正确的以及为什么。
还是仅仅是项目中使用的编码标准的问题？
通过属性访问本地（类范围）变量的一个更有力的论据是在类中添加抽象级别。如果您更改与该字段存储方式有关的任何逻辑，则代码的其余部分将不受影响。
例如，您可以将其从局部变量更改为子对象的属性、数据库调用、Web服务调用、类的静态属性等等。进行更改时，它会为您提供一个更改点，即属性，并且您不必更新类的其余部分，因为它们都使用该属性。
此外，使用该属性可以对属性的值应用业务规则，而不必在直接访问字段的每个位置强制执行相同的规则。再次，封装
随着自动属性的引入，显式拥有本地变量的理由就更少了，除非您需要在get/set 上应用业务规则
这取决于您是否要应用在属性setter中实现的任何逻辑，因此您必须根据具体情况做出决定。
当你直接进入私人字段时，你知道该字段正被设置为你所说的内容。
当您遍历Property时，该值将根据setter逻辑进行设置，因此您可以通过分配给该字段的值获得所需的任何业务规则或验证。
很难想出一个规则来说明什么时候做这两件事都是"正确的"，我唯一要说的是，在构造函数初始化中，我几乎永远不会使用Property。
是的，我认为您应该尽可能在类中内部使用属性。属性更灵活，允许您在中心位置添加验证其价值的逻辑。
您还可以将字段的初始化延迟到使用该属性的任何时候，而不是在构造函数中强制执行（或在使用该字段的任何地方）。示例：
class Test {
private int _checksum = -1;
private int Checksum {
get {
if (_checksum == -1)
_checksum = calculateChecksum();
return checksum;
}
}
}
我认为这纯粹是偏好。
不过，我发现自己在C#3.0中使用了更多的属性，并支持自动属性：
class Foo {
public string Value { get; set; }
public void Write() {
Console.Write(Value);
}
}
通常，根据项目编码标准，我在私有类属性的名称前使用"_"或"m"。（如下）
private int mVariable;
private int _Variable;
对于变量前面的那些，我马上意识到我正在处理类的内部变量。然后，当稍后进行调试时，我或其他人可以立即识别出代码正在处理内部私有变量，并进行调整。所以对我来说，这归结为可读性。
始终使用属性，以下是的一些原因
- 易于使用。在visual Studio中，您可以使用"道具选项卡"。您将获得属性片段
- 属性是访问的语言元素，就好像它们是数据成员一样
- .Net framework类使用它，.Net framework支持属性中的数据绑定代码类
- 属性具有方法的所有语言特性。属性可以是虚拟的