Генерация UI от DB - Хороший, плохой, злой?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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