当将我的xaml数据绑定到某些数据时，我经常使用属性的“get”部分来执行某些逻辑。比如给出列表中总计的总和或检查某个东西是否为正数。
例如:
public List<SomeClass> ListOfSomeClass{get;set;}
public double SumOfSomeClass
{
get
{
return ListOfSomeClass.Sum(s => s.Totals);
}
}
public bool SumPositive
{
get
{
if(SumOfSomeClass >= 0)
return true;
else
return false;
}
}
这样我就可以绑定到SumPositive和SumOfSomeClass。这被认为是良好的实践吗？即使它变得更加复杂？还是最好调用一个方法并返回结果？调用另一个类或甚至是数据库呢？
属性获取器应该快速和幂等（即不应执行任何破坏性操作）。虽然在内存中的对象集合上进行迭代是完全可以的，但我不建议在get或set部分中进行重型工作。说到迭代，我仍然会缓存结果以节省几毫秒的时间。
是的，除非它是可能影响性能的操作。在这种情况下，您应该使用方法（因为对最终用户来说，方法可能很慢，而属性将很快，更符合直觉）。
我喜欢你的命名规则，我完全同意使用像你的示例中属性获取器中的内容，如果你正在提供用于绑定的API。
我不同意他人提出的关于把代码移动到一个方法中只因为它计算量大的观点——我从未做出过这样的区分，也从未听过其他人认为一个方法的速度比属性要慢。
我相信调用对象的属性时它们应该是无副作用的。在保证它们不会对更广泛的环境产生影响方面，这要困难得多 - 即使是相对不重要的属性也可能将数据拉入内存，或至少改变处理器缓存或vm状态。
我说“是”，但是尝试将 ListOfSomeClass.Sum(s => s.Totals) 的结果存储在私有变量中。特别是当你使用它超过一次时。
我没有看到任何直接的问题（除非列表非常巨大），但我个人会尽可能使用 myInstance.SomeList.Sum() 方法（.net >= 2.0）。
如果是基本的计算，可以在 Get 属性内部进行，例如字段或集合中的其他属性。正如其他人说的那样，真正的逻辑不应该在 Getter 里完成。
请将那个 getter 改为这个：
public bool SumPositive
{
get
{
return SumOfSomeClass >= 0;
}
}
你已经在使用布尔表达式，不需要显式地返回true或false
在getter / setter中具有复杂逻辑不是一个好的实践。我建议将复杂逻辑移动到单独的方法中（例如GetSumOfXYZ（）），并在属性访问器中使用memorization。
您可以通过使用ObjectDataProvider来避免复杂的属性 - 它允许您定义提取某些数据的方法。
这取决于......如果这是在一个域实体上，我不会支持在getter中具有复杂的逻辑，尤其不是setter。对我而言，使用一个方法表示实体的使用者正在执行一个操作，而getter表示一个简单的检索。
现在如果这个逻辑在 ViewModel 中，我认为 getter 方面会更加可原谅 / 预期。
我认为在访问器和设置器中需要一定程度的逻辑，否则你只是一种复杂的方式来声明你的成员为公共访问。
我将会小心在属性的Getter方法中放入任何逻辑。需要耗费更多的时间的逻辑，就越危险。其他开发者期望Getter方法立即返回一个值，就像获取一个成员变量的值一样。我见过很多情况，开发者在循环的每一次迭代中都使用属性，认为他们只是获取了一个值，而实际上该属性正在做大量的工作。这可能会导致代码执行速度的严重降低。