Как правильно сделать графический интерфейс?

Question

Я работаю над серией различных программных продуктов.Они довольно старые, поэтому мы находимся в процессе их рефакторинга / улучшения.Моему коллеге пришла в голову идея абстрагировать графический интерфейс и запустить его в своем собственном процессе и общаться с логической частью программы через сокеты.Это позволит нам использовать одни и те же компоненты GUI со всеми различными приложениями (сохраняя один и тот же LAF).Итак, мой вопрос: это действительная практика для создания графического интерфейса?Было бы лучше, если бы графический интерфейс был привязан к остальной части программы?Каковы плюсы и минусы различных методов, и есть ли другие методы для реализации GUI?

Спасибо

Answer 1

С правильно разработанными сервисными и презентационными слоями, которые должны быть в полном порядке Подводя итог плюсы и минусы на мой взгляд:

Плюсы:

1. Пользовательский интерфейс физически не связан с логикой, поэтому логические уровни могут быть удалены (или даже автономный BL-сервер для нескольких клиентов). Давайте назовем это «Независимость местоположения бизнес-логики».
2. Возможность создавать разные версии GUI (и не только графические - можно было бы представить BL в качестве службы, например, в качестве конечной точки канала или отчета), "Независимость от платформы GUI", а также подход SOA.
3. Возможность добавить прокси между BL и GUI - в целях безопасности и кэширования. Или балансировщик нагрузки перед фермой приложений. Или адаптер для поддержки «старых» клиентов после значительных изменений BL. («Отказоустойчивость и отказоустойчивость»?)
4. Развертывание может быть в некоторой степени проще (исправление ошибок в пользовательском интерфейсе не повлияет на уровень BL - только следствие независимости двоичного модуля)
5. Возможность добавить «автономный режим» в графический интерфейс.

Минусы:

1. Вы добавляете еще одну ссылку для подключения, которая может стать еще одной точкой отказа, и для ее проверки необходимо потратить некоторые усилия.
2. Увеличение трафика данных между GUI и BL и, возможно, больше работы по сериализации.
3. Необходимо отслеживать изменения протокола связи и правильное ведение версий протокола.
4. (Отрицательная сторона прокси-способности) Возможность атаки "человек посередине" между GUI и BL.

Answer 2

Зависит от типа приложения.

Настольные приложения

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

Веб-приложения

Да. Многие веб-приложения имеют отдельный уровень обслуживания и используют SOAP для связи между графическим интерфейсом пользователя и уровнем обслуживания.

Гнезда

Использование ванильных розеток сегодня редко бывает хорошим выбором. Зачем тратить энергию / время на создание собственного протокола и реализацию, когда доступно несколько отличных инфраструктур IPC.

Обновление в ответ на комментарий

Разделяй и властвуй. Разбейте пользовательский интерфейс на как можно более мелкие компоненты, чтобы их можно было повторно использовать. Поместите эти компоненты в отдельный проект / DLL. Примером компонента может быть UserTable, который представляет список всех пользователей (с учетом зависимости интерфейса IUserService).

Не пытайтесь повторно использовать весь слой пользовательского интерфейса, поскольку он обречен на провал. Причина в том, что если вы попытаетесь создать пользовательский интерфейс, который должен быть настраиваемым и универсальным, вы, вероятно, в конечном итоге будете тратить на это больше времени, чем это потребовалось бы для создания конкретного пользовательского интерфейса с использованием повторно используемых компонентов. И, наконец, вам нужно добавить небольшие «хаки», чтобы внести незначительные изменения в общий уровень пользовательского интерфейса для каждого приложения. Это закончится в emss.

Вместо этого используйте вышеупомянутые компоненты для создания определенного пользовательского интерфейса для каждого приложения.

Answer 3

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

Это немного необычно для настольного приложения, но вполне приемлемо. Прелесть этого решения в том, что оно позволяет создавать несколько многофункциональных клиентов для разных платформ (например, мобильного приложения, приложения для Windows, приложения на основе браузера и т. Д.)

Все, что вам нужно сделать, это определить API, который GUI должен будет использовать для взаимодействия с серверной частью. Например, ему потребуется способ получения объектов и сохранения объектов, а также получение уведомлений от серверной части о необходимости обновления пользовательского интерфейса.