где я должен сохранить сложное состояние пользовательского интерфейса приложения MVC?

Question

Я смотрел на несколько сред MVC (например, rails, merb, cakephp, codeignitier и т. П.)

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

У меня есть пара приложений, созданных с помощью какой-то платформы, созданной с использованием классического ASP.

Этот фреймворк обрабатывает некоторые элементы CRUD, немного более сложные, чем примеры, которые я нашел.

Что-то вроде master-detail, фильтрации по примеру, разбивки на страницы, сортировки и тому подобного.

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

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

Как вы думаете, какой самый лучший подход для достижения такого рода функциональности?

скрытые входы, встроенные в представление и используемые из контроллера ??? (Полагаю, это будет эквивалентно тому, что я делаю прямо сейчас в Classi Asp)

-

(добавлено в ответ на tvanfosson)

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

Я не уверен, каковы преимущества и недостатки использования строки запроса вместо скрытых входных данных ???

Answer 1

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

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

Контекстно-зависимые настройки - например, текущий столбец сортировки или номер страницы, управляются с помощью параметров запроса. Элементы управления (ссылки) подкачки и сортировки создаются с соответствующими параметрами запроса, чтобы «делать правильные вещи» при нажатии и передавать все необходимые параметры запроса для поддержки или обновления текущего контекста элемента управления. Использование параметров запроса позволяет вам использовать HTTP GET, который можно добавить в закладки, а не POST. Использование скрытых параметров формы значительно усложняет для пользователя сохранение или ввод URL-адреса, который приводит их непосредственно туда, куда они хотят. Это, вероятно, более полезно для сортировки, чем для подкачки страниц, но принцип применяется в равной степени.