Как создать гибкие веб-формы в ASP.NET

Question

Я использую asp.net и мне нужно создать приложение, в котором мы можем легко создавать формы без воссоздания базы данных и, предпочтительно, без изменения запросов на создание / чтение / обновление / удаление. Цель состоит в том, чтобы позволить клиентам создавать свои собственные формы с выпадающими списками, текстовыми полями, флажками и даже отношением «многие к одному» с другой простой формой (это растягивает ее). Пользователь не должен иметь возможность создавать формы самостоятельно, но я не хочу добавлять таблицы, поля, запросы, веб-страницу и т. Д. Каждый раз, когда запрашивается / изменяется новая форма.

2 вопроса: 1) Как мне создать гибкую базу данных для этого (в SQL Server)? Я могу придумать два пути: а) Создать таблицу для каждого типа данных (int, varchar (x), smalldatetime, bit и т. Д.). Это было бы очень сложно создать адекватные запросы. б) Создайте таблицу форм с большим количеством дополнительных полей и различных типов данных на случай, если пользователю нужно 5 целых или 5 полей даты. Это кажется самым простым, но, вероятно, довольно неэффективным использованием пространства.

2) Как я строю формы? Я думал о создании листа XML, который имел валидации, тип данных, элемент управления для отображения и т. Д. В виде списка. Затем я бы проанализировал XML для создания формы на лету. Вероятно, используя css, чтобы сделать макет (это должно быть вручную, что нормально).

Есть ли лучший / лучший способ? Есть ли что-то, на что я мог бы взглянуть, чтобы получить идеи? Любая помощь очень ценится.

Answer 1

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

В этой статье дается краткий обзор создания формы InfoPath, основанной на источнике данных SQL.

http://office.microsoft.com/en-us/infopath-help/design-a-form-template-based-on-a-microsoft-sql-server-database-HP010086639.aspx

Я создал полностью индивидуальное решение, как вы описываете, и если бы я когда-либо делал это снова, я бы, вероятно, выбрал либо 1) сторонний продукт, либо 2) меньшую функциональность.Вы можете потратить 90% своего времени на работу с 10% набора функций.

РЕДАКТИРОВАТЬ: перечитайте свои вопросы и получите дополнительные отзывы.

1 - Гибкая структура данных: Нужно помнить пару вещей: производительность и возможность писать отчеты по данным.Чем более общая структура данных, тем труднее будет ее достичь (опять же, исходя из опыта).

В некоторой степени противоречащей как производительности, так и готовности отчетов, Microsoft SharePoint максимально использует фрагменты / документы XML в общих таблицах.гибкость.Я не могу поспорить с функциями SharePoint, так что это делает работу и значительно упрощает структуру данных.XML будет работать хорошо, когда все сделано правильно, но большинству людей будет труднее писать запросы к XML.Несмотря на то, что XML является «гражданином первого класса» для SQL Server, он может работать или не работать так же, как оптимизированная структура таблиц.

2 - формы: Я реализовал пользовательские формы с использованиемXML преобразован с помощью XSLT.XML часто является хорошим выбором для хранения структуры форм;XSLT - монстр сам по себе, но он очень мощен.Что бы это ни стоило, InfoPath хранит свою структуру форм в формате XML.

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

Наконец (снова на примере SharePoint), Microsoft внедрила ужасно сложный список XML /определения форм в SharePoint 2007. Сложность сводит на нет многие преимущества.Другими словами, если вы идете по XML-пути, сделайте ваши структуры чистыми и простыми, или у вас будет кошмар обслуживания в ваших руках.

РЕДАКТИРОВАТЬ # 2: В связи с вопросом Скотта ниже, вот высокий уровеньструктура данных, которая позволит избежать дублирования данных и не полагаться на XML для большинства определений форм.

Предостережение: я просто собрал этот проект в SQL Management Studio ... Я потратил всего 10минут на это;Разработка гибкой системы форм не является тривиальной задачей, так что это упрощение.Он не касается хранения введенных пользователем данных, только определение формы.

Таблицы:

Форма - top-таблица уровней уровня, которая содержит (как вы могли бы догадаться) коллекцию полей, составляющих форму.

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

FormField - позволяет форме содержать 0 полей;в его определении. Вы могли бы даже расширить эту таблицу, чтобы указать, что пользователь может ДОБАВИТЬ столько полей, сколько ему нужно.

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

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

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

Answer 2

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

Например ...

UserForms
---------
FormID
FieldName
FieldValue

FormID относится к родительской форме (так что вы можете объединить все поля для одной формы. FieldName - это имя текстового поля, введенного из. FieldValue - значение, введенное / выбранное для этого поля.

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

В любом случае, надеюсь, это даст вам возможность задуматься о том, как бы вы хотели чего-то добиться. Удачи!

P.S. Я обнаружил, что использование веб-форм с .NET вызывает большие трудности при создании динамических форм. В тех случаях, когда мне приходилось это делать, я почти полностью отказался от него и использовал нативные элементы HTML. Затем переписал мою форму, используя необходимые значения из Request. Возможно, тоже не идеальное решение, но оно сработало лучше для меня.

Answer 3

Мы создали систему форм, подобную той, которую вы описываете, со схемой, очень похожей на ту, что была в конце поста Тима.Это было довольно сложно, и нам действительно пришлось бороться со стандартными элементами управления WebForms, такими как DetailsView и GridView, чтобы они могли выполнять операции CRUD с группами ответов.Они используются для прямой привязки к свойствам объекта, и мы заставляем их сначала искать идентификатор поля в словаре.Им это не нравится.Вы можете рассмотреть возможность использования MVC.

Один сложный вопрос - как хранить ответы.В итоге мы использовали таблицу с ключами FieldId, InstanceId (например, если 10 человек заполняют вашу форму, есть 10 экземпляров) и RowNumber (потому что мы поддерживаем многострочные формы для таких вещей, как история занятости).Вместо того, чтобы делать это таким образом, я бы рекомендовал сделать ваш AnswerRow первоклассным понятием с привязкой собственной таблицы к экземпляру и привязкой ответов к AnswerRow и полю.

Чтобы поддерживать различные типы значений, нам пришлось создать несколько полей ответов в нашей таблице ответов (AnswerChar, AnswerDate, AnswerInt, AnswerDecimal).Каждый из этих карт соответствует одному или нескольким типам полей (дата, время, номер и т. Д.).Каждый тип поля имеет свою собственную логику для представления значения в пользовательском интерфейсе и помещает значение в соответствующее свойство в наших объектах ответа.

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