Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
> Признаком, что данные получены будем считать не пустое значение свойства ItemsSource.
По мне так скверная идея. Мало ли почему очищается ItemsSource. Если следовать паттерну MVVM, то ничто не мешает во ViewModel завести свойство IsBusy и биндить к нему ваш адорнер.
Сам индикатор должен быть свойством контрола, для которого он должен показываться, а не его родителем в дереве.
> При синхронной работе ситуация вроде как упрощается, но использование MVVM-модели всё-равно требует дополнительных телодвижений.
При переходе на асинк телодвижений дополнительных будет ровно столько, сколько требует обновления самой логики на асинхронную работу. И дело тут не в паттерне MVVM.
По мне так скверная идея. Мало ли почему очищается ItemsSource. Если следовать паттерну MVVM, то ничто не мешает во ViewModel завести свойство IsBusy и биндить к нему ваш адорнер.
Сам индикатор должен быть свойством контрола, для которого он должен показываться, а не его родителем в дереве.
> При синхронной работе ситуация вроде как упрощается, но использование MVVM-модели всё-равно требует дополнительных телодвижений.
При переходе на асинк телодвижений дополнительных будет ровно столько, сколько требует обновления самой логики на асинхронную работу. И дело тут не в паттерне MVVM.
>> > Признаком, что данные получены будем считать не пустое значение свойства ItemsSource.
>> По мне так скверная идея. Мало ли почему очищается ItemsSource. Если следовать паттерну MVVM, >> то ничто не мешает во ViewModel завести свойство IsBusy и биндить к нему ваш адорнер.
Не спорю, можно завести свойство
Разумеется могут встретится случаи когда пустое значение
>>Сам индикатор должен быть свойством контрола, для которого он должен показываться, а не его >>родителем в дереве.
Тут я не понял, что вы имели в виду? Можно разъяснить? О каком свойстве контрола идёт речь?
>> По мне так скверная идея. Мало ли почему очищается ItemsSource. Если следовать паттерну MVVM, >> то ничто не мешает во ViewModel завести свойство IsBusy и биндить к нему ваш адорнер.
Не спорю, можно завести свойство
IsBusy, но что будет написано в геттере этого свойства? Посмотрите на приведенный код DataList — ItemsSource никогда не будет равняться null, кроме как в момент получения значения. Зачем же городить огород? В самом начале я сказал, что моей целью есть минимизация кода. Разумеется могут встретится случаи когда пустое значение
ItemsSource будет означать пустой список, а не промежуточное перед получением данных значение, и в таких редких случаях, естественно нужно делать так, как предложили вы. Но в 99% случаев можно упростить, я считаю.>>Сам индикатор должен быть свойством контрола, для которого он должен показываться, а не его >>родителем в дереве.
Тут я не понял, что вы имели в виду? Можно разъяснить? О каком свойстве контрола идёт речь?
> Зачем же городить огород?
На этот вопрос вы сами ответите, когда кастомеру понадобится, к пирмеру, очистить содержимое ListBox, но при этом индикатор занятости чтобы был выключен.
«Мухи отдельно, котледы врозь...»
Оверхед от дополнительного свойства мизерный по сравнению с теми ограничениями арзитектуры, которые вы огребаете без него.
И как раз в 99% случаев в разработке корпоративного софта вы ДОЛЖНЫ получить пинок от ревьюеров насчет такого «WTF-code».
> Тут я не понял, что вы имели в виду? Можно разъяснить? О каком свойстве контрола идёт речь?
Пусть есть у нас кастомный контрол, для которого мы должны иметь возможность показать индикатор занятости. Заводим в нем свойство BusyIndicator, при выставке которого в сам этот индикатор прокидывается ссылка на «оборачиваемый индикатором контрол» (наш кастомный контрол).
Этот индикатор должен уметь добавлять оборачиваемому контролу AdornerLayer и закидываться в этот AdornerLayer.
На этот вопрос вы сами ответите, когда кастомеру понадобится, к пирмеру, очистить содержимое ListBox, но при этом индикатор занятости чтобы был выключен.
«Мухи отдельно, котледы врозь...»
Оверхед от дополнительного свойства мизерный по сравнению с теми ограничениями арзитектуры, которые вы огребаете без него.
И как раз в 99% случаев в разработке корпоративного софта вы ДОЛЖНЫ получить пинок от ревьюеров насчет такого «WTF-code».
> Тут я не понял, что вы имели в виду? Можно разъяснить? О каком свойстве контрола идёт речь?
Пусть есть у нас кастомный контрол, для которого мы должны иметь возможность показать индикатор занятости. Заводим в нем свойство BusyIndicator, при выставке которого в сам этот индикатор прокидывается ссылка на «оборачиваемый индикатором контрол» (наш кастомный контрол).
Этот индикатор должен уметь добавлять оборачиваемому контролу AdornerLayer и закидываться в этот AdornerLayer.
>> На этот вопрос вы сами ответите, когда кастомеру понадобится, к пирмеру, очистить содержимое ListBox,
>> но при этом индикатор занятости чтобы был выключен.
Пустое значение списка — это список с нулевым количеством элементов, а вовсе не null. По крайней мере, я придерживаюсь именно такой концепции.
> Пусть есть у нас кастомный контрол, для которого мы должны иметь возможность показать индикатор
Согласен, для кастомного контрола — это правильно, но если речь идёт о стандартных контролах? А в большинстве случаев так оно и есть.
Хотя можно сделать
>> Этот индикатор должен уметь добавлять оборачиваемому контролу AdornerLayer и закидываться в этот
>>AdornerLayer.
Да и индикатор может быть любым, в одном проекте у меня Telerik, в другом DevExpress, в третьем ещё что-то.
>>И как раз в 99% случаев в разработке корпоративного софта вы ДОЛЖНЫ получить пинок от
>> ревьюеров насчет такого «WTF-code».
Тоже согласен, код не очевидный, потому-то мне он в итоге не понравился и я решил переделать его под attached property.
>> но при этом индикатор занятости чтобы был выключен.
Пустое значение списка — это список с нулевым количеством элементов, а вовсе не null. По крайней мере, я придерживаюсь именно такой концепции.
> Пусть есть у нас кастомный контрол, для которого мы должны иметь возможность показать индикатор
Согласен, для кастомного контрола — это правильно, но если речь идёт о стандартных контролах? А в большинстве случаев так оно и есть.
Хотя можно сделать
attached property IsBusy для контрола-селектора.>> Этот индикатор должен уметь добавлять оборачиваемому контролу AdornerLayer и закидываться в этот
>>AdornerLayer.
Да и индикатор может быть любым, в одном проекте у меня Telerik, в другом DevExpress, в третьем ещё что-то.
>>И как раз в 99% случаев в разработке корпоративного софта вы ДОЛЖНЫ получить пинок от
>> ревьюеров насчет такого «WTF-code».
Тоже согласен, код не очевидный, потому-то мне он в итоге не понравился и я решил переделать его под attached property.
> Пустое значение списка — это список с нулевым количеством элементов, а вовсе не null. По крайней мере, я придерживаюсь именно такой концепции.
Очень много крови пролито в холиваре о том, каким должно быть значение по умолчанию дл свойств вида List<ЧегоТоТам>.
Если у ViewModel по умолчанию значение списка будет null, то везде придется ставить проверку на null. Либо как минимум в геттере свойства. ViewModel должна по умолчанию отдавать значение так, чтобы это не приводило к появлению эксепшнов, т.е. пустую коллекцию/список и т.д. Где список пустой будет создан — в конструкторе или в самом геттере свойства — не важно.
И еще… вроде если по биндингу в ItemsSource прилетит значение null, то биндинг, вроде, генерит ошибки, которые тихо мирно проглатываются. И вроде бы «и фих с ним», но при ОЧЕНЬ большой частоте возникновения эксепшнов будет серьезно нагружаться GC — в результате страдает первоманс.
Очень много крови пролито в холиваре о том, каким должно быть значение по умолчанию дл свойств вида List<ЧегоТоТам>.
Если у ViewModel по умолчанию значение списка будет null, то везде придется ставить проверку на null. Либо как минимум в геттере свойства. ViewModel должна по умолчанию отдавать значение так, чтобы это не приводило к появлению эксепшнов, т.е. пустую коллекцию/список и т.д. Где список пустой будет создан — в конструкторе или в самом геттере свойства — не важно.
И еще… вроде если по биндингу в ItemsSource прилетит значение null, то биндинг, вроде, генерит ошибки, которые тихо мирно проглатываются. И вроде бы «и фих с ним», но при ОЧЕНЬ большой частоте возникновения эксепшнов будет серьезно нагружаться GC — в результате страдает первоманс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматический BusyIndicator для асинхронных операций и не только