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

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

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

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

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

Я немного запутался!

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

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

3 ответов


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

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

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

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

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

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

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


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

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

Это приложение должно работать в веб-ферме / "облаке" / за балансировщиком нагрузки? Если да, то у вас либо есть кому:

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

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

или

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

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

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

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

надеюсь, что это помогает!


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

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

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

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