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

Question

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

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

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

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

• В общем
• В Java / Swing

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

Answer 1

Есть несколько способов сделать это. Тем не менее, это очень зависит от ситуации.

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

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

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

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

Answer 2

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

Конфигурация, управляемая макетом формы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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

2. Построить матрицу объектов, где каждый клиент может определить свои собственные требования, отметив соответствующие флажки (Поле отключено, Обязательное настоящее, Необязательное настоящее и т. Д.). Он ограничивает то, как вы можете представить свою информацию в пользовательском интерфейсе - вы стремитесь к более простому дизайну, но он масштабируемый и гибкий.
3. Иметь пользовательскую страницу для каждого клиента, где каждая страница поддерживает себя с точки зрения бизнес-логики и проверки. Возможно, вам удастся избежать 3 или 4 вариантов, предлагаемых каждому клиенту.
4. ветвление. Если вы сделаете это, убедитесь, что клиент платит, потому что это дорогой PITA.

Answer 4

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

Answer 5

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

Answer 6

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

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