Кто должен показывать курсор-часики на время длительных операций?

Логика? Вроде бы нет, потому что в конце концов может она сейчас без UI крутится или UI не блокирует.
UI? Вроде бы тоже нет, потому что откуда ему знать, какие операции логики потребуют часиков.

Когда-то велоспидил такое:
в логике:

using (LongProcess.New())
{
    ...
}

А уже этот LongProcess в зависимости от того, в UI потоке или нет, менял или нет курсор.
Можно и дальше пойти, позволить UI подсунуть свою реализацию.

Совсем велосипед? Годное решение для промышленного кода?

Здравствуйте, ylem, Вы писали:

Y>Кто должен показывать курсор-часики на время длительных операций?

Y>Логика? Вроде бы нет, потому что в конце концов может она сейчас без UI крутится или UI не блокирует.
Y>UI? Вроде бы тоже нет, потому что откуда ему знать, какие операции логики потребуют часиков.

Хм, я бы вообще на любое действие включал его. Если быстро мелькнёт, не страшно, но если без объяснения будет ни на что не реагировать — это хуже.

Здравствуйте, ylem, Вы писали:

Y>Логика? Вроде бы нет, потому что в конце концов может она сейчас без UI крутится или UI не блокирует.
Y>UI? Вроде бы тоже нет, потому что откуда ему знать, какие операции логики потребуют часиков.

Внезапно, это один из немногих примеров, на котором можно объяснить IoC.

У нас есть UI, который может, но не знает когда.
У нас есть биз-логика, которая знает когда, но по определению не может.

Особого выбора тут нет, только спрятать часть "я могу показывать уведомления" за события / интерфейс и подсовывать её в бизнес-логику.
В коде будет выглядеть так же, как и у тебя, но ничего не мешает допилить до прогресса / возможности отмены, аля

using (var scope = notifyService.OpenLongRunningScope("бла-бла-бла"))
{
  // ...
  scope.NotifyProgress(0.1, "...");
  // ...
  if (scope.CancelRequested) return ...;
  // ...
}

(нормальные имена лень придумывать).

Какие ещё варианты?

Здравствуйте, netch80, Вы писали:

N>Хм, я бы вообще на любое действие включал его. Если быстро мелькнёт, не страшно, но если без объяснения будет ни на что не реагировать — это хуже.

В принципе да, но надо допилить: на reactive прикрутить задержку перед отображением курсора на полсекунды + показывать курсор не меньше, чем секунду. Тогда норм будет.
И добавить observable.switch (или как там его) на случай, если несколько операций запускаются вперемешку.

S>Внезапно, это один из немногих примеров, на котором можно объяснить IoC.

Если LongScope со статическим методом Open() конфигурится* так же статически, это считается за иньекцию или хотя бы приемлемый способ конфигурации IoC?
Если нет, можно в двух словах, почему?

* кофигурится — например, подсовывается колбэк, возврщающий, что должен вернуть этот Open.

Здравствуйте, ylem, Вы писали:

S>>Внезапно, это один из немногих примеров, на котором можно объяснить IoC.

Y>Если LongScope со статическим методом Open() конфигурится* так же статически, это считается за иньекцию или хотя бы приемлемый способ конфигурации IoC?
Y>Если нет, можно в двух словах, почему?

Код выше — иллюстрация передачи интерфейса обратного вызова (callback), чтобы можно было изменить поведение сервиса (показать часики когда надо),
не меняя сам сервис, и не втаскивая зависимость от UI-библиотек в сервис. Можно сказать да, иллюстрация принципа IoC.

Y>* кофигурится — например, подсовывается колбэк, возврщающий, что должен вернуть этот Open.

Конфигурация IoC тут как-то ни при чем.
Что обычно называется "инъекцией" — это чтобы этот интерфейс "обратного вызова" не в параметрах метода передавался, а в параметрах конструктора например.
Даже больше — чтобы не ты его явно в сервис передавал, создавая этот самый сервис, а поручил эту заботу какой-нибудь библиотеке.

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

Здравствуйте, ylem, Вы писали:

Y>Кто должен показывать курсор-часики на время длительных операций?

"Часиками" должен заниматься код в UI.
Пишешь по образцу проектирования Future. При вызове из UI асинхронной процедуры (которая может выполняться заметное время, не блокируя UI) ставишь для курсора "часики" (а ненужные элемены управления UI делаешь неактивными, чтобы повторно случайно или преднамеренно не нажимались кнопки запуска процедур процесса, который уже запущен). В обработчике оповещения завершения процедуры, "часики" с курсора снимаешь (и элементы разблокируешь).
Вот как-то так.

Здравствуйте, ylem, Вы писали:

Y>Кто должен показывать курсор-часики на время длительных операций?

Y>Логика? Вроде бы нет, потому что в конце концов может она сейчас без UI крутится или UI не блокирует.
Y>UI? Вроде бы тоже нет, потому что откуда ему знать, какие операции логики потребуют часиков.

UI всё будет делать, потому что запустит таймер и если операция будет выполняться дольше секунды, например, то сменит курсор, а если ещё дольше, то покажет окошко какое с преждупреждением. И всё — простая логика и никакой связи с кодом, делающим реальную работу.