Question

当我将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。这被认为是好习惯吗？即使它变得比这更复杂？或者更好地调用方法并返回结果？如何调用另一个类甚至数据库？

Answer 1

预计物业获取者将是快速且幂等的（即不应在那里执行破坏性行为）。尽管迭代内存中的对象集合是完全可以的，但我不建议在 get 或 set 部分中进行任何繁重的工作。说到迭代，我仍然会缓存结果以节省几毫秒。

Answer 2

是的，除非这是一项可能会影响性能的操作。在这种情况下，您应该使用一种方法（因为对于最终用户来说，方法可能会很慢，而属性会很快）

Answer 3

我说是的，但是尝试存储一个私有变量de ListOfSomeClass.Sum（s =＆gt; s.Totals）的结果。特别是如果你不止一次使用它。

Answer 4

在getter / setter中使用复杂的逻辑并不是一个好习惯。我建议将复杂逻辑移到单独的方法（如GetSumOfXYZ（））并在属性访问器中使用memoization。

您可以使用ObjectDataProvider来避免复杂的属性 - 它允许您定义拉取某些数据的方法。

Answer 5

我没有看到任何直接问题（除非列表非常庞大）但我个人会尽可能使用myInstance.SomeList.Sum()方法（.net＆gt; = 2.0）。

Answer 6

对于字段或集合中其他属性的基本计算，可以在Get属性中执行此操作。正如其他人所说，真正的逻辑永远不应该在吸气器中完成。

Answer 7

请将吸气剂更改为：

public bool SumPositive
{
  get
  {
     return SumOfSomeClass >= 0;
  }
}

您已经在使用布尔表达式，无需显式返回true或false

Answer 8

我喜欢您的命名约定，如果您要提供用于绑定的API，我完全同意在属性获取器中使用您的示例等内容。

我不同意其他人将代码转移到方法中的观点仅仅是因为它计算量很大 - 这不是我曾经做过的区别，也没有听到其他人认为在方法中意味着更慢而不是财产。

我确实认为属性应该在调用它们的对象上没有副作用。保证它们对更广泛的环境没有影响要困难得多 - 即使是一个相对微不足道的属性也可能将数据拉入内存或者至少改变处理器缓存或虚拟机状态。

Answer 9

取决于......如果这是在域实体上，那么我不会赞成在getter中使用复杂的逻辑，尤其不是setter。使用方法（对我来说）向实体的消费者发出信号，表示正在执行操作，而获取者则表示简单检索。

现在，如果这个逻辑在ViewModel中，那么我认为getter方面有点可原谅/预期。

Answer 10

我认为Getters和Setters中存在某种程度的逻辑，否则你只需要一种令人费解的方式来公开你的成员。

Answer 11

我会谨慎地将任何逻辑放在属性的Getter中。它做得越贵，就越危险。其他开发人员希望getter立即返回一个值，就像从成员变量中获取值一样。我已经看到很多实例，开发人员在循环的每次迭代中使用一个属性，认为他们只是返回一个值，而该属性实际上做了很多工作。这可能是代码执行的主要原因。

逻辑中获得财产的一部分。好的做法？

11 个答案: