Где мне сохранить сложное состояние пользовательского интерфейса приложения MVC?
Я изучал несколько фреймворков MVC (например, rails, merb, cakephp, codeignitier и тому подобное ...)
Все образцы, которые я видел, в основном представляют собой простые и простые страницы CRUD, содержащие всю необходимую информацию в строке запроса и опубликованных значениях полей.
У меня есть пара приложений, созданных на какой-то платформе, построенной на классическом asp.
Этот фреймворк обрабатывает некоторые вещи CRUD немного сложнее, чем примеры, которые я нашел.
Что-то вроде мастер-детали, фильтрация по примеру, разбиение на страницы, сортировка и тому подобное.
У меня есть класс контроллера, который представляет собой просто конечный автомат, который проходит через разные состояния (например, новый, просмотр, фильтр, показ и т. д.), Затем выполняет соответствующее действие в зависимости от возникшего события и, наконец, извлекает необходимую информацию в вызывающая страница.
Для этого у меня есть несколько скрытых входов для сохранения состояния веб-страницы (например, текущий идентификатор, критерии фильтрации, критерии порядка, предыдущее состояние, предыдущее событие, ну, вы поняли)
Как вы думаете, какой подход лучше всего подходит для достижения такой функциональности?
скрытые входы встроены в представление и используются с контроллера ??? (Думаю, это было бы эквивалентом того, что я делаю сейчас в classi asp)
-
(добавлено в ответ на tvanfosson)
в основном, мой вопрос относится к третьей категории, контекстно-зависимой настройке (в отношении двух других категорий, я согласен с вами) информации, которую я хранил в скрытых полях, чтобы сохранить их в строке запроса, я предполагаю, что когда вы нажимаете на на «следующую страницу» вы включаете все, что нужно сохранить, в строку запроса, верно? так что эта часть строки запроса добавляется к каждой ссылке, которая выполняет какое-то действие ...
Я не уверен, каковы преимущества и недостатки использования строки запроса вместо скрытых входов ???
Ответы 1
Я использую разные стратегии в зависимости от характера фактических данных. Вещи, которые являются предпочтениями, например размер страницы по умолчанию, я сохраняю в объекте (таблице) настроек, который связан с текущим вошедшим в систему пользователем, и получаю оттуда при необходимости.
Постоянные настройки, связанные с текущим входом в систему, например настройки фильтров для страницы, сохраняются в сеансе пользователя. Как правило, это вещи, которые, если пользователь устанавливает их в текущем сеансе, должны оставаться неизменными. Я думаю, что настройки фильтров и видимость такие. Если я отфильтровываю список, ухожу от него, чтобы перейти к конкретному элементу, а затем возвращаюсь к списку, я хочу, чтобы мои настройки фильтра были применены повторно, поэтому я делаю его частью сеанса.
Контекстно-зависимые настройки, такие как текущий столбец сортировки или номер страницы, управляются с помощью параметров запроса. Элементы управления разбиением по страницам и сортировки (ссылки) построены с соответствующими параметрами запроса, чтобы «делать правильные вещи» при нажатии и передавать любые необходимые параметры запроса для поддержания или обновления текущего контекста элемента управления. Использование параметров запроса позволяет использовать HTTP GET, который можно добавить в закладки, а не POST. Использование скрытых параметров формы значительно усложняет пользователю сохранение или ввод URL-адреса, который направляет их прямо туда, куда они хотят. Это, вероятно, более полезно для сортировки, чем для разбиения по страницам, но принцип применим в равной степени.
Какое состояние вы сохраняете, что не может быть передано в URL как части пути?