c# - 我真的不应该在属性访问器中做 "long running"事情吗？

Question

如果是这样，为什么？ 什么是“长跑”？

在属性访问器中施展魔法似乎是我作为类设计者的特权。我一直认为这就是 C# 的设计者将这些东西放在那里的原因——这样我就可以做我想做的事。

当然，尽量减少类用户的意外是一种很好的做法，因此在方法中嵌入真正长时间运行的东西(例如，10 分钟的蒙特卡洛分析)是有意义的。

但是假设一个 prop 访问器需要一个数据库读取。我已经打开了数据库连接。数据库访问代码在属性访问器中是否符合正常预期？

Answer 1

正如您提到的，这对类(class)的用户来说是一个惊喜。人们习惯于使用属性来做这样的事情(人为的例子如下:)

foreach (var item in bunchOfItems)
    foreach (var slot in someCollection)
        slot.Value = item.Value;

这看起来很自然，但是如果 item.Value 实际上在您每次访问它时都在访问数据库，那将是一场小灾难，并且应该以等同于此的方式编写:

foreach (var item in bunchOfItems)
{
   var temp = item.Value;
   foreach (var slot in someCollection)
      slot.Value = temp;
}

请帮助引导使用您的代码的人远离这样的隐患，并将慢的东西放在方法中，让人们知道他们很慢。

当然，也有一些异常(exception)。只要延迟加载不会花费一些非常长的时间，延迟加载就很好，有时使事物属性对于反射和数据绑定(bind)相关的原因非常有用，所以也许你会想要弯曲这个规则。但是，如果没有特定的原因，违反惯例和违背人们的期望是没有多大意义的。