LINUX.ORG.RU

Полное разделение логики и приложения

 ,


0

2

Интересует следующее: как лучше реализовать полное разделения GUI и логики, что-бы интерфейс стал такой же частью программы, как например иконка, который можно быстро заменить на любой другой. Что бы GUI никак не зависел от языка, на котором написано само приложение. Что бы при ошибке в GUI, и последующем его перезапуске, сама программа сохраняла свое состояние. И в итоге за то как выглядит конкретная программа, сможет отвечать DE или сам пользователь.

Как лучше организовать в таком случае «общение» между графическим интерфейсом и логикой программы, d-bus или другие способы независимые от него?

Посмотри на transmission.

erfea ★★★★★ ()

Сделать программу сервером, а гуй - клиентом. Можно и на локальных сокетах, как mocp, например.

schizoid ★★★ ()
Ответ на: комментарий от schizoid

Сделать программу сервером, а гуй - клиентом.

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

Noloboot ()
Ответ на: комментарий от erfea

Посмотри на transmission.

Как я понял там прям из кода вызывается библиотека общая(при очень, очень беглом взгляде), значит будет зависит от выбранного языка для логики-сервера программы. Хотя я мог ошибиться со своим беглым взглядом

Noloboot ()
Ответ на: комментарий от Noloboot

Там есть графические клиенты (их несколько) и демон, которые по tcp общаются.

erfea ★★★★★ ()
Ответ на: комментарий от Noloboot

Если у тебя и интерфейс, и логика однозначно будут крутиться на одной машине, то можно выбрать какой-нибудь IPC, типа тех же юникс-сокетов, shared memory.

Но сетевые сокеты универсальнее. Лучше их пока ничего не придумали.

schizoid ★★★ ()

Смотря какова функциональность программы. Отделение интерфейса от логики сродни попыткам сделать микроядерную систему - можно, и способов немало, но результат будет столь тормозным и нефункциональным, что укатает любого фаната. Хорошо ещё, если ты делаешь что-то вроде торрент-клиента, там гуй вторичен.

cache ★★ ()

Бери, mvc как метод разделения. А то, как части mvc между собой будут комуницировать вопрос отдельный, как в классике с обсервер паттерном, а можно обмен сообщениями (с command processor pattern'ом). Но начинать с mvc в любом случае надо.

invy ★★★★★ ()

Логика - консольная утилита, гуй - надстройка.

AlexCones ★★★ ()

Web же. Раздельнее не бывает.

note173 ★★★★★ ()

Между серверной частью и клиентской надо проложить чёткий и до конца документированный интерфейс.

Deleted ()

Паттерн MVC со всеми подвариантами.

Изучай опыт поколений, не изобретай велосипед. :D

ak377630 ()

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

Napilnik ★★★★★ ()

Так серебрянной пули нет, зависит от ситуации. Вот примеры разных вариантов: X-CD-Roast (вызов утилит), SMplayer (управление дочерним процессом через stdin), GMPC (управление демоном по сети), NetworkManager (управление демоном по dbus), Transmission (уже упоминали, демон с rpc на json).

gv ()
Ответ на: комментарий от Napilnik

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

Потоки, глобальные переменные, флаги и статическая линковка. Эталонно вышло :)

gv ()

По поводу MVC, ИМХО отталкиваться надо от протокола между гуи и движком, а потом уже смотреть, подходит ли MVC.

gv ()
Ответ на: комментарий от gv

Потоки, глобальные переменные, флаги и статическая линковка. Эталонно вышло :)

Хоть одну плохую технологию назови.

Napilnik ★★★★★ ()

SOAP, мой друг, только SOAP. Стандартизованное, широко применяемое решение с поддержкой от ведущих производителей программного обеспечения. Тысячи архитекторов бизнес-приложений не могут ошибаться.

anonymous ()

придерживайся при проектироании разделения: MVVM с одной стороны, и SOA - с другой.

d_Artagnan ★★ ()

Что бы при ошибке в GUI, и последующем его перезапуске, сама программа сохраняла свое состояние.

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

subwoofer ★★★★★ ()
Ответ на: комментарий от subwoofer

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

Это просто не спасет, в случае аварийной ошибки, произошедшей где-нибудь в области GUI. Хотя конечно можно сохранять время от времени свое состояние, а потом восстанавливать, но это уже немного другой путь

Noloboot ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.