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

C>Что можно почитать на тему проектирования таких штук?

Правильно сделанное настольное приложение по архитектуре ничем не отличается от любой другой многослойной системы. В общем виде это:

1. UI, который использует
2. Логику, которая использует
3. Подсистему хранения данных проекта

Задача разделения зависимостей между компонентами — эта задача оптимизации графа, где выбирается оптимальные размеры и сочетания узлов графа (т.е. компонентов) и ребер (зависимостей) между ними.

Проектирование как таковое — это целая наука, где все упирается в принцип "разделяй и властвуй".

Тип приложения (настолка, веб) это дело второстепенное. На мой взгляд, настольные приложения делать несколько проще поскольку много функций на себя берет ОС. Например, управление пользователями и их правами. В веб приложениях всё намученней, частно нужны велосипеды.

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

A>Правильно сделанное настольное приложение по архитектуре ничем не отличается от любой другой многослойной системы. В общем виде это:

Я не могу согласиться. В настольном приложении нам важен отклик. В приложении-редакторе, где есть взаимодействие с трёхмерной графикой, блоками текста нам в квадрате важен отклик. Чем слабее у нас связаны компоненты, тем больший путь проходят сигналы от источника до приёмников, и тем больше становится время отклика. А ещё при слабой связности нужно решить вопрос целостности данных и корректности типов. Вот об этом всём и был вопрос.

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

BE>Почему бы не сделать один UI на Qt? Или на Electron? VS Code на Electron работает нормально, так что можно пробовать.

Электрон? Смешно Не, для текста, может, эта штука и работает (съев перед этим всю доступную память), но у меня трёхмерная графика. Qt могло бы работать, но у меня неприятный опыт со всякимим пороируемыми штуками, которые косят под nativ. Я не вижу проблем с написанием UI дважды.

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

BE>>Почему бы не сделать один UI на Qt? Или на Electron? VS Code на Electron работает нормально, так что можно пробовать.

C>Электрон? Смешно Не, для текста, может, эта штука и работает (съев перед этим всю доступную память), но у меня трёхмерная графика. Qt могло бы работать, но у меня неприятный опыт со всякимим пороируемыми штуками, которые косят под nativ. Я не вижу проблем с написанием UI дважды.

Вот вам миллион точек в рендеринге жээсом. Можете поставить параметр побольше, я пробовал 10, 20 и 100 млн. Работает внятно, безо всякого военного ускорителя.
Можете даже в телефоне повтыкать

https://dgerrells.com/sabby?count=1000000

Не агитирую за JS, впрочем.

P.S. Если вам интересно посмотреть варианты реализации C в MVC, можете глянуть Mediatr, правда эти товарищи упрятали самые внятные примеры кудато подальше. Гляньте их гитхаб. На мой взгляд, для тяжелого десктопа это просто что надо.

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

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

A>>Правильно сделанное настольное приложение по архитектуре ничем не отличается от любой другой многослойной системы. В общем виде это:

C>Я не могу согласиться. В настольном приложении нам важен отклик. В приложении-редакторе, где есть взаимодействие с трёхмерной графикой, блоками текста нам в квадрате важен отклик. Чем слабее у нас связаны компоненты, тем больший путь проходят сигналы от источника до приёмников, и тем больше становится время отклика. А ещё при слабой связности нужно решить вопрос целостности данных и корректности типов. Вот об этом всём и был вопрос.

У тебя графика 2D или 3D?

Если 3D, то выбор там маленький. Раньше бы я взял OpenGL (и какую-нибудь толковую книгу по нему). Честно говоря, не знаю, как сейчас обстоят дела в 2025 году с 3D-графикой. С графикой 3D сам почти не работал.

Если 2D, то можно по-старинке самому работать с графикой (MFC, .NET WinForms, Java Swing, GTK3), а можно по модно-молодежному через сценический граф (.NET WPF, Avalonia, GTK4). Самое смешное, что если работать по-старинке, то программа может быть и более отзывчивой, жрать меньше ресурсов, и работать быстрее, хотя не всегда. Причем, я даже не уверен, что модно-молодежный способ даже проще, если ты немного владеешь навыками в аналитической геометрии и в двоичных деревьях. Хотя, если с математикой не дружишь, то тогда сценический граф без вариантов. Что касается С++ Qt и графики 2D, то вроде как там возможны оба варианта (??).

В общем, накидал названия, по которым можно найти соответствующие книги. Может быть, кто-то дополнит свое. Обычно в книгах есть шаблоны того, как писать код. Как правило, сам тулкит диктует то, как ты будешь организовывать код — здесь нет смысла сопротивляться.

Пока же твои вопросы кажутся несколько абстрактными. Может быть, ты сам и знаешь, что хочешь спросить, но я пока этого не понимаю

C>CAD, IDE, всякие текстовые редакторы. Можно долго не думать и сделать клиент-сервер, слабую связность везде, но два вопроса:
CAD мож и тяжелое, а IDE и текстовый редактор — нет.
C>1. Накладные расходы -> теряется скорость отклика.
Это ты про клиент-сервер ?
C>2. Как задавать зависимости между компонентами? Например, есть компоненты А и B. Если А работает, то B должен подождать. Но для этого B должен знать про существование А, а это уже не слабая связность. Можнно вввести блокировки ресурсов, конечно, но это банальные варианты из головы, потому что я не проектировал такие штуки никогда.
Дык пусть о запускаемых компонентах знает главный компонент, который их и запускает. Он знает о всех, а они друг о друге могут и не знать.
Да MVC — прямо в книжке GoF в начале расписано на примере текстового редактора.