«Глобальное» состояние и ASP.NET MVC

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

Там, кажется, три варианта:

Просто поместите информацию в состояние сеанса. Хорошо работает, но не очень MVC-ish
Вставить состояние во все URL-адреса ... так что вместо/Продукты/Детали/1 все URL-адреса/(project_id)/Продукты/Подробности/1
Настройка отдельный файл cookie для этой информации

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

Любые предложения по наилучшему подходу - это использование такой плохой идеи ?!

источник

2010-03-09 Rob Walker

Что не-MVCisch о сеансе? –

Масштабируемость, по-видимому, является главной задачей. Любое состояние на стороне сервера влияет на способность приложения масштабироваться. Для этого проекта я просто пытаюсь понять мышление MVC более полно. –

Его un-mvc ish в том, что его не совсем соответствует стилю REST, который похож на mvc. Сессия в основном используется только по умолчанию для хранения сообщений об ошибках между действиями. В любом случае использование его затрудняет тестирование. – DevelopingChris

Вариант 2 из вашего - мой выбор.
Таким образом, вместо/Продукты/1/Детали
Я хотел бы сделать это проект/1/Продукты/1/Детали

Его просто больше в соответствии с REST. Это практически не имеет отношения к MVC, но если вы хотите, чтобы ваши маршруты и URL-адреса читались как ресурсы в REST, вам нужно, чтобы URL-адрес рухнул на косые черты и нести состояние. Другие способы - отметить идентификатор проекта в cookie, но это убивает связь, так что, когда кто-то уходит и возвращается, они возвращаются туда.

Сессия также затрудняет тестирование, если вы привязываетесь непосредственно к этой концепции.

источник

2010-03-09 22:04:07 DevelopingChris

Добавление префикса проекта имеет смысл. Для тестирования я не уверен. Я могу издеваться над ним в сеансе достаточно легко, тогда как если он является параметром при каждом вызове метода контроллера, он также должен быть передан намного больше. Тем не менее, я дам этот подход, чтобы посмотреть, как это работает на практике. (Не знаете, почему это привлекло проголосовать?) –

+1 от меня. Это работает как закладка. Сессия и файлы cookie не будут. –

Я пробовал оба подхода, и использование URL-маршрутизации работало хорошо. Это немного больше, чтобы генерировать URL-адреса, но работает довольно гладко с помощью общего метода Html.ActionLink . Преимущества возможности соединения определенно перевешивают проблемы. –

Лично я бы просто использовал сеанс. Ничего не отличного от MVCish о сеансе - подумайте, что это просто часть вашей модели.

Использование файла cookie на самом деле не отличается от сеанса. Внедрение этого в URL-адресах - неплохой вариант, особенно для «связывания», если это касается вашего проекта. Но у него есть побочный эффект загромождения URL-адресов, и вам необходимо постоянно передавать этот идентификатор со страницы на страницу.

источник

2010-03-09 21:55:49

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

«Глобальное» состояние и ASP.NET MVC

ответ

Смежные вопросы