Привет, не могу промолчать)) За глубину приверженности идее — респект! Но вдруг кто-нибудь решит проникнуться, а я против, это сплошная идеологическая ошибка!)))))
1) Борьба за мелко-гранулярную реактивность изнутри модели — лишняя писанина (очень много писанины) обреченная на провал. Провал наступит когда кнопке надо будет подписаться на результат функции вычисляющей валидна ли операция тригерящаяся к кнопке. В том и сила Rx, что отображение может из единственного Observable изменений модели в целом Select'ить себе то что нужно. Поуправлять Throttling'ом для «отложенности» и все что хочешь… Вообще, реактивность не должно быть свойством модели — это бессмыслица, например с т.з приложения которое реализует точно такую же бизнес логику но не имеет UI вообще (именно таким приложением является сервер ;) ). Реактивность — это свойство способа, которым отображение получает данные из модели.
2) Команда — хороший паттерн для реализации (на самом деле нет, потому что правильное место данным описывающим изменения — в DTO без кода) но плохой способ предоставлять API. Хороший способ предоставлять API это интерфейс с функциями с понятной сигнатурой и контрактом. Полезность команд для реализации такого интерфейса в этом кейсе — ну, дело вкуса, мне кажется и это баловство.
3) Запихивать стейт и прочие подробности отображения в модель бизнес-логики — странно, неудобно и неправильно. Описание танцев с бубнами которые нужны для того чтобы потом отделить одно от другого — лучшее тому подтверждение. Я в принципе могу согласиться с понятием «модель интерфейса» как стейта отображения, но мухи отдельно. Но если честно, ее отдельное выделение — довольно бесполезная трата времени имо. Полезная трата времени — выделение «нормального» слоя для логики отображения — вью-контроллера, презентера, вью-модели — как угодно, но нельзя его не выделять, для него объективно существует область ответственности (отдельная от модели и вью).
1) Борьба за мелко-гранулярную реактивность изнутри модели — лишняя писанина (очень много писанины) обреченная на провал. Провал наступит когда кнопке надо будет подписаться на результат функции вычисляющей валидна ли операция тригерящаяся к кнопке. В том и сила Rx, что отображение может из единственного Observable изменений модели в целом Select'ить себе то что нужно. Поуправлять Throttling'ом для «отложенности» и все что хочешь… Вообще, реактивность не должно быть свойством модели — это бессмыслица, например с т.з приложения которое реализует точно такую же бизнес логику но не имеет UI вообще (именно таким приложением является сервер ;) ). Реактивность — это свойство способа, которым отображение получает данные из модели.
2) Команда — хороший паттерн для реализации (на самом деле нет, потому что правильное место данным описывающим изменения — в DTO без кода) но плохой способ предоставлять API. Хороший способ предоставлять API это интерфейс с функциями с понятной сигнатурой и контрактом. Полезность команд для реализации такого интерфейса в этом кейсе — ну, дело вкуса, мне кажется и это баловство.
3) Запихивать стейт и прочие подробности отображения в модель бизнес-логики — странно, неудобно и неправильно. Описание танцев с бубнами которые нужны для того чтобы потом отделить одно от другого — лучшее тому подтверждение. Я в принципе могу согласиться с понятием «модель интерфейса» как стейта отображения, но мухи отдельно. Но если честно, ее отдельное выделение — довольно бесполезная трата времени имо. Полезная трата времени — выделение «нормального» слоя для логики отображения — вью-контроллера, презентера, вью-модели — как угодно, но нельзя его не выделять, для него объективно существует область ответственности (отдельная от модели и вью).