Создание пользовательского интерфейса из БД - хорошо, плохо и безобразно?

Question

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

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

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

Добавлено: Найдено Этот несколько связанный вопрос

Добавлено 2: Хорошо, похоже, что один из способов получить довольно хорошие результаты - это наличие достаточного количества метаданных, связанных с презентацией. Для этого подхода, сколько будет «достаточно», и будет ли это меньше работы, чем разработка формы вручную? Обеспечивает ли это также большую гибкость для будущих изменений?

Answer 1

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

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

Answer 2

это нормально для чего-то крошечного, где все, что вам нужно, это утилитарный метод для ввода данных.

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

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

edit - чтобы уточнить: пользовательский интерфейс, сгенерированный из code / db, хорош как отправная точка, это просто мусорная конечная точка.

Answer 3

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

Примером из реальной жизни является корпоративное программное обеспечение MS Dynamics AX.

Имеется база данных 'Данные' и база данных 'Модель' .

'Model' хранит формы, классы, задания и все артефакты, необходимые приложению для запуска.

Развертывание новой структуры программного обеспечения, которая использовалась для выгрузки базы данных модели и запуска компиляции CIL (CIL для общего промежуточного языка, что используется Microsoft в .net)

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

Answer 4

Можете ли вы взглянуть на свою проблему с точки зрения архитектуры приложения? Я вижу вас как еще одного террориста базы данных - пытающегося все решить, написав хранимые процедуры. Зачем вообще иметь интерфейс? Попробуйте сделать это в скрипте БД. В результате такого подхода - на какой композитной системе вы окажетесь? Когда система обслуживает разные предприятия - попробуйте модульность, выборочно обнаруженные компоненты, ограничьте обмен ссылками. Пользовательский интерфейс должен быть сменным, независимым от бизнес-уровня. При хранении такого количества данных в БД - существует жесткая зависимость UI - система становится монолитной. Как вы реализуете шаблон MVVM в сценарии, когда генерируется пользовательский интерфейс? Дизайнеры, такие как Blend, содержат множество функций, которые не могут быть заменены большинством футуристических генераторов пользовательского интерфейса, если только ваша платформа разработки - только Блокнот.

Answer 5

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

Но это зависит от того, откуда взялась БД. Если он был создан, чтобы точно отражать цели пользователей системы. Если в базе данных хранится ментальная модель пользователей, в чем им должно помочь приложение. Тогда это может просто сработать. Но тогда у вас есть , чтобы начать со стороны пользователей. Если нет, то я предлагаю вам не идти этим путем.

Answer 6

В моем Мнении есть несколько вещей, о которых вы должны подумать:

1. Нужна ли клиенту функция для настройки его интерфейса?
2. Много ли разных атрибутов или элементов?
3. Стоит ли усилий по созданию такого "движка рендеринга"?

Хорошо, я думаю, это довольно очевидно, почему вы должны думать об этом. Это действительно зависит от вашего проекта, если такая модель имеет смысл ... Если вы хотите создать много форм, которые можно настроить во время выполнения, эта модель может быть очень полезной. Кроме того, если вам нужно сделать много небольших инструментов, и вы используете это как своего рода «движок», тогда эти усилия могут стоить того, потому что вы можете сэкономить много времени. С помощью такого «движка рендеринга» вы можете автоматически добавлять отчеты об ошибках, проверять значения или добавлять другие элементы, которые всегда создаются по одному и тому же шаблону. Но если у вас слишком много таких вещей, элементов или атрибутов, производительность может быстро снизиться. Еще одна вещь, которая становится интересной в больших проектах, это то, что изменения, которые должны происходить в каждой форме, просто должны быть сделаны в движке, а не в каждой форме. Это может сэкономить МНОГО времени, если в готовом приложении будет ошибка.

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

Answer 7

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

Я использовал XML для сохранения метаданных для такого рода вещей. некоторые атрибуты, которые я сохранил для каждого поля, были:

1. friendlyname (подпись к надписи)
2. имеет предопределенные значения (да для отбрасывания вниз список / список нескольких флажков)
3. множественный выбор (если да, то установите флажок список, если нет, то выпадающий список)
4. тип данных
5. MaxLength
6. обязательны для заполнения
7. MinValue
8. MAXVALUE
9. RegularExpression
10. включено (показывать или не показывать)
11. sortkey (заказ в веб-форме)

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

ОБНОВЛЕНИЕ: также обратите внимание, что многие продукты электронной коммерции следуют этому динамическому интерфейсу, когда вы хотите ввести информацию о продукте - поскольку их клиенты могут продавать все под солнцем, от мебели до секс-игрушек ;-), так что вместо переписывания кода для каждой отрасли они просто позволяют своим клиентам вводить метаданные для атрибутов продукта через форму администратора: -)

Я бы также порекомендовал вам взглянуть на Модель Entity-attribute-value - у нее есть свои плюсы и минусы, но я чувствую, что ее вполне можно использовать с вашими требованиями.