Добрый день! Прошу прощения за опоздание с ответом — не сразу увидела Ваш комментарий.
Перед решением не использовать реактивные команды мы не рассматривали этот вариант в принципе (из-за отсутствия опыта использования Reactive UI ранее он просто выпал из области рассмотрения).
Возможно, Ваш вариант с ReactiveCommand был бы более удачным решением (особенно, учитывая описанные недостатки интеракций). Я не имею абсолютно никаких нареканий к ICommand в WPF, и использовать то же самое в Xamarin лично для меня было бы более комфортно
Всё-таки Reactive UI — это не то же самое, что System.Reactive. Главной целью использования Reactive UI в нашем случае была связка бэкэнд-UI. Используя только асинхронное программирование, вы не сможете без лишних велосипедов оповестить интерфейс об изменениях на бэкэнде. Конечно, вы можете использовать INotifyPropertyChanged, но тут я вынуждена отправить вас перечитать текущую статью, где написано о минусах такого подхода в чистом виде.
Разумеется, использование любого стороннего фреймворка добавляет накладных расходов — тут я спорить не буду. Поэтому и выбирается золотая середина между допустимыми «тормозами» и удобством программирования. В нашем случае Reactive UI нагрузил систему недостаточно, чтобы отказаться от его использования :)
Перед решением не использовать реактивные команды мы не рассматривали этот вариант в принципе (из-за отсутствия опыта использования Reactive UI ранее он просто выпал из области рассмотрения).
Возможно, Ваш вариант с ReactiveCommand был бы более удачным решением (особенно, учитывая описанные недостатки интеракций). Я не имею абсолютно никаких нареканий к ICommand в WPF, и использовать то же самое в Xamarin лично для меня было бы более комфортно
Разумеется, использование любого стороннего фреймворка добавляет накладных расходов — тут я спорить не буду. Поэтому и выбирается золотая середина между допустимыми «тормозами» и удобством программирования. В нашем случае Reactive UI нагрузил систему недостаточно, чтобы отказаться от его использования :)