Логика в get часть собственности. Хорошая практика?

при привязке моего 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. Считается ли это хорошей практикой? Даже если все станет сложнее? Или лучше вызвать метод и вернуть результат? Как насчет звонков в другой класс или даже в базу данных?

7
c# data-binding properties wpf

11 ответов

ожидается, что геттеры свойств будут быстрыми и идемпотентными (т. е. там не должны выполняться деструктивные действия). Хотя это совершенно нормально перебирать коллекцию объектов в памяти, я бы не рекомендовал делать какой-либо тяжелый подъем в любом get или set запасные части. И, говоря об итерации, я все равно кэширую результат, чтобы сэкономить несколько миллисекунд.

14

да, если это не операция, которая может иметь последствия для производительности. В этом случае вместо этого вы должны использовать метод (поскольку для конечного пользователя более интуитивно понятно, что метод может быть медленным, а свойство-быстрым)

2

Я говорю Да, но попробуйте сохранить на частной переменной de результаты ListOfSomeClass.Sum (s => s.Итоги). Особенно, если вы используете его более одного раза.

1

Я не вижу никакой прямой проблемы (если список не очень огромен), но я бы лично использовал myInstance.SomeList.Sum() метод, если это возможно (.нетто >= 2.0).

1

для базовых вычислений полей или других свойств в коллекции было бы приемлемо сделать это внутри свойства Get. Как все остальные говорили, истинная логика никогда не должна выполняться в геттере.

1

пожалуйста, измените этот геттер на это:

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

вы уже используете логическое выражение, нет необходимости явно возвращать true или false

1

наличие сложной логики в геттерах / сеттерах не является хорошей практикой. Я рекомендую переместить сложную логику в отдельные методы (например, GetSumOfXYZ ()) и использовать memoization в свойствам.

вы можете избежать сложных свойств с помощью ObjectDataProvider - это позволяет определить метод, чтобы вытащить некоторые данные.

1

Мне нравятся ваши соглашения об именах, и я полностью согласен с использованием контента, такого как ваш пример в геттерах свойств, если вы предоставляете API для использования с привязкой.

Я не согласен с точкой зрения других о перемещении кода в метод только потому, что он вычислительно тяжелый - это не различие, которое я когда-либо делал, и я не слышал, чтобы другие люди предполагали, что быть в методе означает медленнее, чем свойство.

Я считаю, что свойства должны будьте свободны от побочных эффектов на объекте, на котором они вызваны. Гораздо сложнее гарантировать, что они не влияют на более широкую среду - даже относительно тривиальное свойство может вытащить данные в память или, по крайней мере, изменить кэш процессора или состояние виртуальной машины.

1

зависит... если бы это было на объекте домена, я бы не был за наличие сложной логики в геттере и особенно не сеттере. Использование метода (для меня) сигнализирует потребителю объекта, что операция выполняется, а геттер сигнализирует о простом извлечении.

теперь, если эта логика была в ViewModel, то я думаю, что аспект геттера немного более простителен / ожидаем.

0

Я думаю, что есть некоторый уровень логики, который ожидается в Геттерах и сеттерах, иначе у вас просто есть какой-то запутанный способ объявить своих членов публичными.

0

Я был бы осторожен, помещая любую логику в Геттер свойства. Чем дороже это сделать, тем опаснее. Другие разработчики ожидают, что геттер немедленно вернет значение, как и получение значения из переменной-члена. Я видел много случаев, когда разработчик использует свойство на каждой итерации цикла, думая, что они просто возвращают значение, в то время как свойство на самом деле делает много работы. Это может быть серьезным замедлением в коде исполнение.

0