Лучшая практика для защиты модели после того, как пост в MVC3

Что является лучшей практики для защиты от нежелательной модели синтаксического анализа/обновления после поста в MVC3Лучшая практика для защиты модели после того, как пост в MVC3

Регулятор называется в HttpGet-> Product/Edit:

public ActionResult Edit() 
     { 
      Product p = new Product(); 
      p.Id = 1; 
      p.Name = "PC"; 
      Category cat = new Category(); 
      cat.Id = 1; 
      cat.Name = "Non food"; 
      p.Category = cat; 

      return View(p); 
     }

Это Edit View:

@model MvcApplication3.Models.Product 
@using (Html.BeginForm("Edit", "Product", FormMethod.Post)) 
{ 
    @Html.HiddenFor(model => model.Id) 
    @Html.EditorFor(model => model.Name) 
    <input type="submit" value="Submit" name="go" /> 
}

После того, как браузер получает ответ, пользователь вставляет следующий HTML сегмент на странице:

<input type="text" value="5" name="Category.Id" id="Category_Id"/>

Он отправляет форму, а следующее действие контроллера получает параметр «Продукт».

// 
    // POST: /Class1/Edit/5 

    [HttpPost] 
    public ActionResult Edit(Product p) 
    { 
     //Here: p.Company.Id is 5 !!! 
     db.Save(p); 
     return null; 
    }

Проблема в том, что пользователю не разрешается публиковать/обновлять c.Company.Id. Мне не хотелось бы проверять всю структуру параметров на наличие нежелательных значений. Im ищет наилучшую практику для решения проблемы.

Любая помощь приветствуется!

Bests,

Boolish

источник

2012-03-07 Boolish

Вы можете отделить полученный тип объекта (т.е. ViewModel) от типа объекта сохраняется в базе данных, как описано в this recent blog post Джош Буш. Хорошо стоит прочитать - актуально также, поскольку это связано с недавней аналогичной проблемой, испытываемой GitHub.

например.

public ActionResult Edit(ProductModel p) 
{ 
    // Map ProductModel -> a Product instance 
    // Then save 
}

источник

2012-03-07 11:42:34 AdaTheDev

Спасибо за ответ! Я согласен с тем, что модели представления разумны в сложном системном случае. Если модель представления требует агрегированных/преобразованных данных из модели db, она также должна быть разумной и т. Д. Причинам. Но если Id нравится создавать довольно простую систему, всего пять-десять таблиц с основными CRUD-действиями, это может быть огромным усилием для создания нескольких моделей представлений и двунаправленного сопоставления (утверждения Automapper Ignor в модели db для просмотра направления модели) " просто "для защиты модели db. ... – Boolish

Когда отправленные данные поступают в связующее данные, связующее данные данных создает новый ViewModel и заполняет свойства. (отражение) Затем я должен прочитать модель db и создать «simmilar» модель (та же структура, кроме защищенных реквизитов в модели представления), и сопоставить модель представления модели db. (По AutoMapper - снова отражение. Рукой это не время эффективно.) ... – Boolish

Я думал, что-то вроде ... Разработчик говорит где-то/как-то: - Модель всего db (единственная) и все ее свойства защищены (например, жестко закодированное правило) - Исключения для защиты в зависимости от фактического контекста. (например: в сеансе) - привязка отправленных данных непосредственно к модели db (если это возможно, в противном случае новая модель) в соответствии с правилами/исключениями защиты. (использование отражения только один раз) Каково Ваше мнение? – Boolish

Вот почему вы должны использовать вид модели, а не БД объектов в ваших взглядах

http://blog.gauffin.org/2011/07/three-reasons-to-why-you-should-use-view-models/

источник

2012-03-07 11:47:51 jgauffin

Уважаемый jgauffin, Спасибо за ваш ответ. Пожалуйста, см. Комментарий, который я написал в ответ AdaTheDev. Тот же вопрос для вас. Каково твое мнение? – Boolish

Лучшая практика для защиты модели после того, как пост в MVC3

ответ

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