У меня есть что-то похожее на следующий метод:
public ActionResult Details(int id)
{
var viewData = new DetailsViewData
{
Booth = BoothRepository.Find(id),
Category = ItemType.HotBuy
};
return View(viewData);
}
и следующий маршрут:
routes.MapRoute("shows","shows/{controller}/{action}/{id}", new {id = 0});
Все работало нормально до бета-версии, когда у меня был Preview 3. Теперь метод правильно заполнит идентификатор при первом выполнении действия. Однако во второй раз ModelState контроллера содержит значение идентификатора последнего использования. Это заставляет ActionInvoker использовать его в параметре метода вместо значения Route.
Итак, если я дважды вызываю действие для двух разных объектов, результаты будут такими:
www.mysite.com/shows/Booth/Details/1 => Details(1)
www.mysite.com/shows/Booth/Details/2 => Details(1) //from ModelState["id"]
Из моего быстрого сканирования с помощью Reflector кажется, что он сначала связывает параметры с ModelState, а затем с Routes. Однако я даже ничего из модели не выкладывал. Насколько я могу судить, ModelState ничего не должен содержать.
Это ошибка в бета-версии, возможно, ошибка где-то в моем коде, или есть какая-то особенность дизайна, о которой я не знаю? Приветствуется любое понимание природы ModelState и того, почему это происходит.
Обновлено: Я обнаружил, что эта проблема на самом деле является симптомом того, что кажется ошибкой с DefaultValueProvider, если вы создаете экземпляр контроллера из контейнера IoC, который существует в течение всего времени существования приложения Asp.Net. Что происходит, так это то, что DefaultValueProvider использует первый ControllerContext передается контроллеру и никогда не обновляет его до тех пор, пока контроллер не будет воссоздан. Это заставляет старые RouteData использоваться для параметров метода вместо текущих RouteData.





Мне сложно сказать, что вы ожидаете от вашего сообщения и что происходит. Возможно ли, что в вашем методе BoothRepository.Find есть такая ошибка, что он каждый раз возвращает одно и то же?
ModelBinder не должен влиять на этот метод, поскольку параметр метода действия имеет простой тип int.
Были ли оба этих запроса запросами GET? Если у вас все еще есть проблемы, можете ли вы попробовать создать простейшую копию и отправить ее по электронной почте philha - microsoft dot com?
Обновлено: проблема заключалась в том, что разработчик пытался повторно использовать поставщик значений для разных запросов (за счет управления жизненным циклом контроллеров Castle Windsor). Прямо сейчас нет поддержки для повторного использования экземпляров контроллера в запросах, как если бы вы использовали IHttpHandler, у которого есть свойство IsReusable. В общем, повторное использование контроллеров в запросах требует гораздо больше работы с вашей стороны. :)
Это не ошибка в репо. Репозиторий напрямую от Rhino.Commons. Я определил это в GetParameterValue (ParameterInfo) actionInvoker. Я пришлю вам баребонную версию, когда у меня будет время. Спасибо за ответ.
Кроме того, да, это были запросы GET. Вот почему я запуталась? Я думал, что ModelState будет заполняться только на неудачных POSTS.
Я считаю, что его можно заполнить, если вы передали недопустимый параметр методу действия даже в запросе GET. Например, если было передано id = "ABC", но id - это целое число.
Я трижды проверил веб-страницу, но ввода с идентификатором не существует. Это также происходит с обычным POST. Основная причина, по-видимому, в том, что DefaultValueProvider удерживает устаревший ControllerContext. Его контекст не соответствует текущему ControllerContext контроллера.
Проблема в LifeStyle, я полностью упустил из виду тот факт, что он был определен, что означает, что по умолчанию контроллеры будут использовать стиль жизни Singleton. Установка LifeStyle на Transient для всех контроллеров решит эту проблему.
На самом деле это решение, к которому я пришел в конце концов.
если вы используете spring.net, измените Singleton контроллера на "false"
Это распространенная проблема при использовании поведения Singleton с контейнером IoC, например Spring.NET или Windsor. Контроллеры не должны иметь одноэлементного поведения, потому что ControllerContext предназначен для каждого запроса, как и HttpContext.
Не могли бы вы отметить один из приведенных ниже ответов как ответ, чтобы я больше не отвечал на этот вопрос. :П