ASP.NET MVC - передача данных через представления

Question

Я создаю приложение MVC. Одна из моих задач - построить магазин. Я установил «вид мастера», как набор представлений, который позволяет пользователю заполнять различные типы данных до конца операции, всего 7 шагов.

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

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

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

Я немного растерялся!

Моя путаница связана со всеми этими структурами: сессия (я знаю, что это происходит из asp.net), ViewData, TempData и магия ViewBag.

Я много читал о, но мне нужен кто-то, кто четко скажет мне, что мне больше подходит в этом случае.

Answer 1

Я бы сказал, что ViewBag идеально подходит для чего-то подобного.Теперь вы ссылаетесь на ViewBag как на «волшебный» viewbag, но на самом деле он просто оборачивает ViewData, который представляет собой словарь <string,object>

. Способ работы ViewBag заключается в том, что это просто динамическая оболочкавокруг ViewData, поэтому, когда вы запрашиваете что-то, скажем ViewBag.ShoppingCart, он в основном спрашивает базовый словарь, есть ли у него запись «ShoppingCart», и возвращает элемент.

UPDATE Проблема в том, что я не помню, чтобы ViewBag и ViewData зависели от вида, поэтому они очищаются всякий раз, когда вы нажимаете на другое представление / действие.

Если вам не требуется, чтобы ShoppingCart (или Wizard-progress) былхранится в базе данных, я бы пошел на ViewBag TempData в вашем случае:)

Вы также можете взглянуть на эту статью от Рэйчел Apple для получения дополнительной информации о трех:

http://rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3-applications

(PS. Я бы рекомендовал прочитать комментарии к этому посту, чтобы получить более объективные мнения)

Answer 2

Ничего плохого в использовании скрытых полей - по крайней мере, в моей книге.

Я бы "исправил" проблему Session вместо того, чтобы пытаться писать код вокруг этой проблемы.Запустите простой тест: измените поставщика Session на SQL, отключите скрытые поля и посмотрите, правильно ли работает ваше приложение.Если это не так, есть другие (более крупные) проблемы, о которых вам нужно беспокоиться.

Должно ли это приложение работать в веб-ферме / «облаке» / за балансировщиком нагрузки?Если это так, вам нужно:

• изменить поставщика сеанса на что-то другое: SQL, StateServer, memcache и т. Д. Не требуется много изменений кода.

http://msdn.microsoft.com/en-us/library/ms178587.aspx и http://memcachedproviders.codeplex.com/

ИЛИ

• измените дизайн шагов мастера и уменьшите зависимость от общих значений между представлениями.Идентификатор сеанса - это все, что вам нужно, и вы можете запросить у БД что-нибудь еще.Не очень быстро, но безопасно и стабильно.

Оптимизация: используйте столько скрытых полей, сколько хотите, чтобы уменьшить количество запросов к БД (как я уже сказал, в этом нет ничего плохого), но обычно достаточно одного поля для сохранения вашего сериализованного состояния между запросами:http://blog.maartenballiauw.be/post/2009/10/08/Leveraging-ASPNET-MVC-2-futures-ViewState.aspx.

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

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

Надеюсь, это поможет!

Answer 3

У вас есть несколько вариантов здесь: Используйте сеанс, viewdata (или viewbag), но нужно передать его, используя скрытые поля или куки.

Viewdata имеет проблему, которая даст больше работы.

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

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