стратегии / шаблоны для обработки сложных веб-форм?

Question

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

Класс Crud задуман как своего рода «конечный автомат»

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

это некоторые из состояний, которые мы обрабатываем до сих пор

запрос: позволяет пользователю вводить критерии запроса для фильтрации данных.

browse: показывает данные в виде таблицы. с нумерацией страниц, заказом и т.д ...

новое, редактирование, удаление: ну, довольно очевидно

browse-single: как редактировать, но только для чтения

и т.д ...

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

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

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

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

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

что вы думаете об этом подходе?

как вы справляетесь с такими вещами?

какой шаблон вы можете мне посоветовать посмотреть?

как вы отслеживаете состояние формы?

Answer 1

Я сам использовал этот подход и был довольно успешным.

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

Возможные варианты: хранить данные в файлах cookie браузера. поэтому они не так заметны.

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

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

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

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

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

Answer 2

Звучит разумно.

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

Выясните, где вам нужна гибкость:

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

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

Вы также можете взглянуть на Rails Active Scaffold, (да, я не знаю ASP), который решает проблему аналогичным образом, предоставляя несколько точек расширения.