2009-01-30 53 views
7

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

回答

14

属性吸气剂预计是快速和幂等的(即不应该在那里执行破坏性行为)。尽管遍历内存中的对象集合是完全正确的,但我不会推荐在获取集合部分进行任何类型的繁重工作。说到迭代,我仍然会缓存结果以节省几毫秒。

+1

“保存几毫秒” - 纳秒? – 2009-01-30 15:34:04

+1

幂等具有比这更广泛的含义 - 它意味着通过反复调用操作获得相同的结果,而不是受到记忆状态的影响。 http://en.wikipedia.org/wiki/Idempotent – 2009-01-30 15:44:39

1

我说是的,但尝试存储ListOfSomeClass.Sum(s => s.Totals)的私有变量de结果。特别是如果你多次使用它。

1

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

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

1

我没有看到任何直接的问题(除非列表非常大),但如果可能的话我会亲自使用myInstance.SomeList.Sum()方法(.net> = 2.0)。

1

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

0

取决于......如果这是一个域实体,那么我不会赞成在一个getter中有复杂的逻辑,尤其是不是一个setter。使用一种方法(对我)向实体的消费者发出正在执行操作的信号,而吸气剂发出简单的检索信号。

现在,如果这个逻辑是在一个ViewModel中,那么我认为getter方面更容易理解。

0

我认为在Getters和Setters中有一定的逻辑级别,否则你只是有一种复杂的方式来公开你的成员。

2

是的,除非它是一种可能会影响性能的操作。在这种情况下,你应该使用一个方法,而不是(因为它是更直观的最终用户,一个方法可能是缓慢的,而属性会很快)

1

请改变吸气到这一点:

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

你已经在使用布尔表达式,不需要明确地返回true或false

1

我喜欢你的命名约定,我完全同意在属性获取器中使用诸如你的例子之类的内容,如果你提供了一个API来使用具有约束力。

我不同意别人提出的关于将代码移入方法的观点,因为它的计算量很大 - 这不是我所做过的区别,也没有听说其他人认为在方法中暗示比物业慢。

我确实认为属性应该在被调用的对象上是无副作用的。要保证它们不会对更广泛的环境产生影响是非常困难的 - 即使是相对较小的属性也可能将数据拉入内存或至少更改处理器缓存或虚拟机状态。

0

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