Продолжение комментария ...
Допустим, у вас есть модель с именем Toy
. Игрушка обладает свойствами, такими как Name
, Price
и Category
:
public class Toy()
{
public string Name;
public double Price;
public string Category
}
Теперь вы хотите построить форму View, чтобы добавить Toy
, и люди должны иметь возможность выбрать категорию из выпадающего списка возможностей ... но вы не хотите делать это с помощью ViewData
или ViewBag
по какой-то причине.
Вместо передачи модели в представление, создайте ToyViewModel
, который имеет Name
, Price
, Category
... но также имеет коллекцию категорий для заполнения капли вниз:
public class ToyViewModel()
{
public string Name;
public double Price;
public string Category
public ICollection<string> Categories;
}
Теперь ваш контроллер делает это:
public ActionResult GetToyForm()
{
var viewModel = new ToyViewModel();
viewModel.Categories = _service.GetListOfCategories();
return View(viewModel);
}
Ваш View привязан к ViewModel, и вы используете коллекцию model.Categories
для заполнения вашего раскрывающегося списка. Он должен выглядеть примерно так:
@Html.DropDownListFor(model => model.Category, model.Categories)
Когда вы отправляете его, ваш контроллер делает что-то вроде:
[HttpPost]
public ActionResult CreateToy(ToyViewModel _viewModel)
{
var model = new Toy();
model.Name = _viewModel.Name
// etc.
_service.CreateToy(model);
// return whatever you like.
return View();
}
Хорошей практикой является создание ViewModels для привязки к Views, чтобы вы могли адаптировать их к потребностям вашего уровня представления, в то время как ваши Модели остаются близкими к уровню данных и бизнес-логике.