Архитектура Desktop-приложения на .NET 10: Зачем я разделил UI и логику через gRPC

[HemulGM]

Для этого существуют "службы", которые работают отдельно от UI части. При этом, общение можно тоже реализовать "нативным" способом, например, через COM, который более гибок по части протокола взаимодействия.

Помимо этого, не обязательно основную логику делать именно в основном потоке. Более того, это даже антипаттерн. В Андроид за такое вообще система ругает сильно.

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

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

[WhiteBehemoth]

можно даже и без службы, просто postmessage / sendmessage через старый ламповый Inter-Process Communication (IPC)

(ред: пропустил детали, "просто", при такой задачи не получится).

[MonkAlex]

Немного не нравится входная постановка проблемы.

Использовать БД для хранения данных могут и десктопные приложения, краш или зависание не обязаны терять данные. Зависание решается таймаутами, которые применяются в десктоп разработке вполне аналогично клиент-серверным подходам (это если зависание вне вашего управления, конечно).

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

[SkiF4er]

Здесь, на мой взгляд, самая сильная мысль даже не в самом gRPC, а в том, что вы зафиксировали границу жизненного цикла.

Очень много desktop-проектов пытаются “держать всё рядом”, пока это удобно в разработке, а потом внезапно выясняется, что падение UI — это не визуальная проблема, а фактический отказ всей системы. В этом смысле перенос состояния, таймеров и интеграций в отдельный headless-контур выглядит не как усложнение, а как возвращение контроля над системой.

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

[HemulGM]

Почему вы допускаете "падение UI", что к слову вообще несуществующий термин в десктоп-разработке, но опускаете тот факт, что отдельный процесс с "бизнес-логикой" - это точно такой же процесс, который точно так же может упасть как любой другой процесс?

Стабильность работы десктоп-приложения зависит исключительно от вашего кода (и кода библиотек и фреймворков).