Лучшая практика настройки версионного пользовательского интерфейса?
-
29-08-2019 - |
Вопрос
Как бы наилучшим образом реализовать следующий сценарий:
В версии 1.0 существует стандартизированный пользовательский интерфейс для приложения, напримерформа заказа.Это приложение настраивается в соответствии с потребностями различных клиентов.Это может быть дополнительное поле "желаемое время доставки" для клиента A, отсутствие поля "номер телефона" для клиента B, дополнительный плагин карты, который показывает близлежащие склады для клиента C, и их комбинация для клиента D.
Теперь разработчик выпускает новую версию стандартизированной формы заказа, версию 2.0.Каков наилучший способ спроектировать это с минимальными усилиями (если они вообще прилагаются), чтобы убедиться, что все настройки, выполняемые для клиентов, могут быть сохранены?
Я мог бы представить себе следующие решения:
- Конфигурация:все параметры настраиваются.На самом деле это не может быть решением, поскольку невозможно предвидеть все возможные потребности клиентов.
- Наследование:настройки выполняются путем наследования стандартизированной версии.Однако, как можно убедиться, что новый выпуск не приведет к появлению "дрянно" выглядящей настроенной версии?
Решение
Первый вариант, который приходит на ум, - это спецификация пользовательского интерфейса, которая существует вне приложения.Когда приложение запускается, пользовательский интерфейс генерируется во время выполнения.Хотя это требует больше работы, чем статический, скомпилированный пользовательский интерфейс, он также намного более гибкий в долгосрочной перспективе, учитывая ваш конкретный жизненный цикл программного обеспечения.
Существуют фреймворки, которые существуют исключительно для этой цели: СЮЛЬ это один хорошо известный пример.
Однако вы могли бы сделать это самостоятельно.В конечном счете, это дает вам возможность разделять пользовательские интерфейсы ваших клиентов.