Как вы обрабатываете настройки формы для разных клиентов?

Question

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

• У одного клиента есть поле ввода, которого нет у других.
• У другого клиента есть все поля по умолчанию, но одно из необязательных полей ввода является обязательным.
• У третьего клиента есть поля по умолчанию, но заголовок одного поля изменен
• У четвертого клиента появилось несколько новых полей ввода, и одно существующее многострочное поле ввода необходимо заменить на однострочное поле ввода (чтобы освободить место для новых полей).
• ...

(Примечание:Хотя эти примеры могут показаться нелепыми, это то, о чем просили наши клиенты)

Как вы справляетесь с этими делами?

• В целом
• В Java / Swing

В настоящее время мы разработали форму наиболее распространенным способом.Во время выполнения мы вносим коррективы, такие как скрытие, изменение размера или перепозиционирование полей.При проверке входных данных мы проверяем содержимое в зависимости от активного клиента.

Answer 1

Этот вопрос имеет три аспекта:макет формы, хранилище базы данных и настраиваемая бизнес-логика.

Макет формы, основанный на конфигурации

Гибкий подход к компоновке формы может быть достигнут путем перемещения компоновки в файл дескриптора.Тремя графическими наборами инструментов, которые поддерживают это, являются QT, WPF и XUL.Однако AFAIK Swing напрямую не поддерживает эту возможность.QT Jambi действительно позволяет вам использовать QT на Java в качестве альтернативы Swing, а QT 4.5 будет доступен с лицензией LGPL.Это не решение на чистой Java, но может быть возможным, если это и сопутствующая перезапись кода пользовательского интерфейса приемлемы.

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

Настраиваемое хранилище базы данных

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

1. Первый подход заключается в том, чтобы иметь ряд полей "user" в таблице, таких как "User1", "User2" и т.д.Настроенные поля в формах могут быть сопоставлены с этими полями - и реализовать универсальный механизм сопоставления пользовательских полей не должно быть сложно.Это наиболее эффективно с точки зрения запроса к базе данных, но страдает из-за ограничения конечным числом возможных полей.Если у вас есть поля от 'User1' до 'User20', вы можете поддерживать только 20 пользовательских атрибутов.Кроме того, они должны быть удобными, широкими универсальными переменными, так что вы не получите никакой защиты типов от базы данных.

2. Второй подход заключается в том, чтобы иметь таблицу атрибутов, зависшую от объекта.Это не обеспечивает вам безопасность типов, но позволяет вам иметь столько атрибутов, сколько вы хотите.Создание универсального обработчика для этого также вполне осуществимо, но производительность запроса будет снижена, если вы выполните несколько соединений с таблицей атрибутов.

3. Сохраняйте пользовательские поля в большом двоичном объекте XML.Это мало что дает для рекомендации, поскольку затрудняет доступ к данным через базу данных.Тем не менее, я видел, как это делается.

Настраиваемая бизнес-логика

Это гораздо более острый вопрос.Без добавления пользовательского кода и изменения сборки у вас есть несколько вариантов выполнения настраиваемых бизнес-правил:Движки правил, языки сценариев или набор стандартных функций включения / выключения, таких как обязательные поля.

1. Механизмы управления:Вам действительно нужно разработать свое приложение с нуля, чтобы использовать их, и у них есть свои собственные ограничения и слабости.ILOG, действующий в этой области, также довольно дорогой.Для java JESS может быть подходящим вариантом.

2. Встроенный язык сценариев:Добавив интерпретатор для Jython, Groovy или какого-либо другого интерпретируемого языка, дружественного к JVM, вы можете писать подключаемые модули для системы без необходимости выпуска новой сборки.Некоторая нагрузка на тестирование все равно будет понесена, но в целом это может привести к выигрышу в обслуживании.

3. Настройка включения / выключения функций.Это наименее гибкий вариант, но он относительно прост и относительно мало увеличивает затраты на внешние зависимости и лицензирование.Это также может быть вашим единственным выбором, если вы пытаетесь модифицировать конфигурацию для чего-то, что начинало свою жизнь как индивидуальное приложение.

Ничего из вышеперечисленного

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

Answer 2

Есть несколько различных способов добиться этого.Однако это очень зависит от ситуации.

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

2. Пользовательские сборки или филиалы клиентов.Хотя это может стать довольно сложным.

3. Делайте в точности то, что вы уже делали, и встраивайте в экраны логику, специфичную для клиента.

4. Используйте какой-нибудь механизм правил для управления вашим интерфейсом.

Answer 3

Я могу придумать 4 подхода:

1. Не надо.Да, я знаю, что сейчас слишком поздно, но если вам это сойдет с рук, всегда продавайте стандартный продукт.

Если это невозможно...

2. Создайте матрицу функций, где каждый клиент может определить свои собственные требования, поставив галочки (Поле отключено, Присутствует обязательное, присутствует необязательное и т.д.).Это ограничивает то, как вы можете представить свою информацию в пользовательском интерфейсе - вы склоняетесь к более простому дизайну, но он масштабируемый и гибкий.
3. Создайте пользовательскую страницу для каждого клиента, где каждая страница поддерживает саму себя с точки зрения бизнес-логики и проверки.Возможно, вам сойдет с рук 3 или 4 варианта, которые предлагаются каждому клиенту.
4. Ветвление.Если вы сделаете это, убедитесь, что клиент заплатит, потому что это дорогой ЛАВАШ.

Answer 4

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

Используете ли вы какой-либо тип системы управления кодом / контроля версий?SVN - это то, что мы используем, и это позволяет вам обновлять каждую ветвь по мере внесения изменений в основной код, поэтому код никогда не устареет.

Answer 5

Я бы сделал что-то похожее на экран создания форм внутри MS Access, разрешив клиенту добавлять / удалять / изменять и устанавливать входные данные самостоятельно.Это также позволило бы им устанавливать, какие поля являются обязательными, а какие нет.Это означало бы для вас больше работы на переднем плане, но меньше на заднем.

Answer 6

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