1) Если мы используем открытое поле вместо свойств, сериализатор не сериализует объект json в модель C #, поэтому я всегда получаю ноль для
Поле «Имя» в контроллере. Почему так происходит?
Потому что связыватель модели работает только со свойствами. Это по замыслу. Обычно поля должны быть приватными в ваших классах. Это детали реализации. Используйте свойства, чтобы показать некоторое поведение внешнему миру.
2) Если я изменил тип свойства NumArr на List, то он не будет
Работа. Как мы можем использовать List вместо int []? Я знаю, что прохожу
массив из JS. Можем ли мы передать список из JS?
Это должно работать. Неважно, используете ли вы List<int>
, IEnumerable<int>
или int[]
, все одинаково и работает. Что не сработает, так это если вы захотите использовать коллекцию некоторого сложного объекта, такого как, например, List<SomeComplexType>
(см. Мой ответ ниже для решения этой проблемы).
3) Я использую «Traditional: True» в блоке кода Javascript, потому что
сериализация не работает с «традиционным: ложным». я слышал, что
У jQuery есть три версии сериализатора Json. Сериализатор ASP.NET MVC
поддерживает только старую версию. Это правда?
Да, традиционный параметр *1022* был введен в jQuery 1.4, когда они изменили способ сериализации параметров jQuery. Это изменение оказалось несовместимым со стандартным соглашением, которое связыватель модели использует в MVC при привязке к спискам .
Загрузите инструмент отладки javascript, такой как FireBug, и начните играть. Вы увидите различия в том, как jQuery отправляет запрос при установке этого параметра.
При этом я бы порекомендовал вам отправлять запросы в кодировке JSON на действия вашего контроллера. Это будет работать с любыми сложными объектами, и вам не нужно спрашивать себя, какую версию jQuery вы используете или что-то еще, потому что JSON является стандартным совместимым форматом. Преимущество стандартного совместимого формата заключается в том, что независимо от того, какую систему вы используете, вы должны иметь возможность заставить их говорить на одном языке (если, конечно, в этих системах нет ошибок и они не соответствуют определенному стандарту).
Но теперь вы можете сказать мне, что application / x-www-form-urlencoded также является стандартным и неоперабельным форматом. И это правда. Проблема заключается в том, что средство связывания моделей использует соглашение при связывании имени полей ввода в свойствах ваших моделей. И это соглашение далеко от того, чтобы быть совместимым или отраслевым стандартом.
Так, например, у вас может быть иерархия моделей:
public class Person
{
public string Name { get; set; }
public string Occupation { get; set; }
public int Salary { get; set; }
public List<SubObject> SubObjects { get; set; }
}
public class SubObject
{
public int Id { get; set; }
public string Name { get; set; }
}
Вы можете представить любую сложную иерархию, которая вам нравится (за исключением циклических ссылок, которые не поддерживаются форматом JSON).
и затем:
var data = {
name: "Michael Tom",
occupation: "Programmer",
salary: 8500,
subObjects: [
{ id: 1, name: 'sub 1' },
{ id: 2, name: 'sub 2' },
{ id: 3, name: 'sub 3' }
]
};
$.ajax({
url: "Home/GetJson",
type: "POST",
data: JSON.stringify({ person: data }),
contentType: 'application/json',
success: function (result) {
}
});
Мы устанавливаем HTTP-заголовок запроса Content-Type равным application/json
, чтобы указать встроенной фабрике провайдера значений JSON, что запрос закодирован в JSON (с использованием метода JSON.stringify
), и он будет анализировать его обратно в строго типизированный. модель. Метод JSON.stringify
изначально встроен в современные браузеры, но если вы хотите поддерживать устаревшие браузеры, вы можете добавить скрипт json2.js на свою страницу.