Просто создайте интерфейс для возврата вместо класса.
public interface IMyViewModel {
string MyPublicProperty { get; set; }
}
Затем создайте класс, который наследует интерфейс
public class MyViewModel : IMyViewModel {
public string MyPublicProperty { get; set; }
public string MyNotSoPublicProperty { get; set; }
}
И вернуть интерфейс, а не класс, в действии контроллера
public JsonResult MyJson(){
IMyViewModel model = new MyViewModel();
return Json(model);
}
И полученный JSON будет
{
'MyPublicProperty': ''
}
Одна из проблем сценариев на стороне клиента заключается в том, что если вы меняете классы, вы не представляете, разрушаете ли вы реализацию на стороне клиента или нет. Если вы используете типы интерфейсов в вашем JSON, вы понимаете, что если вы меняете интерфейс, вы делаете что-то, что потенциально может убить реализацию на стороне клиента. И это также избавляет вас от тщательной проверки на стороне клиента, если вы изменяете что-то, что НЕ находится в интерфейсе (таким образом, не сериализуется).
Кроме того, во многих случаях ваши ViewModels могут содержать большие коллекции или сложные типы, которые вы не обязательно хотите выводить клиенту. Это может занять много времени для сериализации или раскрытия информации, которая просто не принадлежит клиентскому коду. Использование интерфейсов сделает более прозрачным понимание того, что происходит в выводе.
Кроме того, использование таких атрибутов, как [ScriptIgnore] в свойстве, применимо только к конкретному сценарию (сериализация JavaScript), что заставляет вас столкнуться с точно такой же проблемой, если вы позже сериализуетесь в XML, например. Это излишне засоряет ваши модели представления множеством атрибутов. Сколько из них вы действительно хотите там? Использование интерфейсов применимо везде, и никакой модели представления не нужно засорять дополнительными атрибутами.