Очень важное предостережение, даже в MVC3, о том, как работает MVC3.
Если вы передаете объект, например, скажите:
{
Test: 'Hi'
}
И принимающий класс:
public class MyModel
{
public string Test { get; set; }
}
С приемным методом контроллера, например:
[HttpPost]
public JsonResult Submit(MyModel model)
{
. . .
Это будет работать. Но если в вашем методе Controller есть это очень незначительное, казалось бы, безобидное изменение:
[HttpPost]
public JsonResult Submit(MyModel test)
{
. . .
Это не удастся. Это связано с тем, что среда MVC использует JSON в словаре, как указано выше, и видит, что один из параметров имеет то же имя, без учета регистра, что и один из его ключей ("Test"/"test"). Затем он принимает строковое значение «Привет», присвоенное Test, и передает его этому аргументу «test», даже если это явно не то, что имел в виду автор.
Что наиболее проблематично в этом, так это то, что фреймворк не выдает ошибку, пытаясь присвоить строку аргументу типа MyModel, что, по крайней мере, даст вам представление о том, что пошло не так. Он не видит, что это был неправильный тип и откат к его альтернативному поведению (которое он бы преследовал, если бы эти аргументы/свойства не совпадали по имени). Он просто молча терпит неудачу и присваивает null вашему аргументу, оставляя вас без понятия о том, что происходит.
Я неоднократно сталкивался с этой проблемой и, наконец, нашел сбой, из-за которого вещи, кажется, случайным образом перестают работать в MVC... Надеюсь, это поможет кому-то еще.
Поскольку любое разумное имя для этого аргумента действия является потенциально разумным именем свойства (модель, данные и т. д.) и поскольку оно нечувствительно к регистру, самый безопасный способ предотвратить его без написания собственного связывателя модели — стандартизировать одно, сумасшедшее, очень- имя аргумента, которое вряд ли когда-либо станет именем свойства, например:
[HttpPost]
public JsonResult Submit(MyModel _$_$twinkleTwinkleLittleFuckIt)
{
Но если у вас есть время, исправьте ModelBinder/JsonValueProviderFactory, чтобы свести риск к нулю вместо этой странной ошибки за десятилетие, до которой никто никогда не доберется.
person
Chris Moschini
schedule
19.06.2012