(id != car.Id)
{
return BadRequest();
}
if (ModelState.IsValid)
{
_repo.Update(car);
return RedirectToAction(nameof(Details),new {id = car.Id});
}
ViewData["MakeId"] = GetMakes(makeRepo);
return View(car);
}
Метод действия Edit() для POST принимает один обязательный параметр маршрута id. Если его значение не совпадает со значением Id реконструированной сущности Car, тогда клиенту отправляется ошибка BadRequest. Если состояние модели допустимо, то сущность обновляется, после чего пользователь перенаправляется на метод действия Details() с применением свойства Id сущности Car в качестве параметра маршрута. Здесь также используется шаблон "отправка-перенаправление-получение".
Если состояние модели не является допустимым, то список SelectList с записями Make добавляется в объект ViewData и сущность, которая была отправлена, посылается обратно представлению Edit. Состояние модели тоже неявно отправляется представлению, так что могут быть отображены любые ошибки.
Создайте в каталоге ViewsCars новый файл представления по имени Delete.cshtml. Удалите весь сгенерированный код и добавьте следующую разметку:
@model Car
@{
ViewData["Title"] = "Delete";
}
<h1>Delete @Model.PetName</h1>
<h3>Are you sure you want to delete this car?</h3>
<div>
@Html.DisplayForModel()
<form asp-action="Delete">
<input type="hidden" asp-for="Id" />
<input type="hidden" asp-for="TimeStamp" />
<button type="submit" class="btn btn-danger">
Delete <i class="fas fa-trash"></i>
</button> |
<item-list></item-list>
</form>
</div>
В представлении Delete тоже применяется вспомогательная функция @Html.DisplayForModel() и два скрытых элемента ввода для Id и TimeStamp. Это единственные поля, которые отправляются в виде данных формы.
В рамках процесса удаления используются два метода действий: первый (HttpGet) возвращает сущность, подлежащую удалению, а второй (HttpPut) отправляет значения удаляемой записи.
Метод действия Delete() для GET
Метод действия Delete() для GET функционирует точно так же, как метод действия Details():
[HttpGet("{id?}")]
public IActionResult Delete(int? id)
{
var car = GetOneCar(id);
if (car == null)
{
return NotFound();
}
return View(car);
}
Форму удаления можно просмотреть по ссылке /Cars/Delete/1 (рис. 31.9).
Метод действия Delete() для POST
Метод действия Delete() для POST просто отправляет значения Id и TimeStamp оболочке службы:
[HttpPost("{id}")]
[ValidateAntiForgeryToken]
public IActionResult Delete(int id, Car car)
{
if (id != car.Id)
{
return BadRequest();
}
_repo.Delete(car);
return RedirectToAction(nameof(Index));
}
Метод действия Delete() для POST оптимизирован для отправки только значений, которые необходимы инфраструктуре EF Core для удаления записи.
На этом создание представлений и контроллера для сущности Car завершено.
Компоненты представлений — еще одно новое функциональное средство, появившееся в ASP.NET Core. Они сочетают в себе преимущества частичных представлений и дочерних действий для визуализации частей пользовательского интерфейса. Как и частичные представления, компоненты представлений вызываются из другого представления,но в отличие от частичных представлений самих по себе компоненты представлений также имеют компонент серверной стороны. Благодаря такой комбинации они хорошо подходят для решения задач, подобных созданию динамических меню (как вскоре будет показано), панелей входа, содержимого боковой панели и всего того, что требует кода серверной стороны, но не может квалифицироваться как автономное представление.
На заметку! Дочерние действия в классической инфраструктуре ASP.NET MVC были методами действий контроллера, которые не могли служить конечными точками, видимыми клиенту. В ASP.NET Core они не существуют.
Для AutoLot компонент представления будет динамически создавать меню на основе производителей, которые присутствуют в базе данных. Меню отображается на каждой странице, поэтому вполне логичным местом для него является файл _Layout.cshtml. Но _Layout.cshtml не имеет компонента серверной стороны (в отличие от представлений), так что любое действие в приложении должно предоставлять данные компоновке _Layout.cshtml. Это можно делать в обработчике события OnActionExecuting() и в записях, помещаемых в объект ViewBag, но сопровождать подобное не будет простой задачей. Смешивание возможностей серверной стороны и инкапсуляции пользовательского интерфейса превращает такой сценарий в идеальный вариант для использования компонентов представлений.
Создайте в корневом каталоге проекта AutoLot.Mvc новый каталог по имени ViewComponents и добавьте в него файл класса MenuViewComponent.cs. Подобно контроллерам классы компонентов представлений по соглашению именуются с суффиксом ViewComponent. И как у контроллеров, при обращении к компонентам представлений суффикс ViewComponent отбрасывается.
Добавьте в начало файла следующие операторы using:
using System.Linq;
using AutoLot.Dal.Repos.Interfaces;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.ViewComponents;
Сделайте класс общедоступным и унаследованным от ViewComponent. Компоненты представлений не обязательно наследовать от базового класса ViewComponent, но аналогично ситуации с базовым классом Controller наследование от ViewComponent упрощает большую часть работы. Создайте конструктор, который принимает экземпляр реализации интерфейса IMakeRepo и присваивает его переменной уровня класса. Пока что код выглядит так:
namespace AutoLot.Mvc.ViewComponents
{
public class MenuViewComponent : ViewComponent
{
private readonly IMakeRepo _makeRepo;
public MenuViewComponent(IMakeRepo makeRepo)
{
_makeRepo = makeRepo;
}
}
Компонентам представлений доступны два метода, Invoke() и InvokeAsync(). Один из них должен быть реализован и поскольку MakeRepo делает только синхронные вызовы, добавьте метод Invoke():
public async IViewComponentResult Invoke()
{
}
Когда компонент представления визуализируется из представления, вызывается открытый метод Invoke()/InvokeAsync(). Этот метод возвращает экземпляр реализации интерфейса IViewComponentResult, который концептуально подобен PartialViewResult, но сильно упрощен. В методе Invoke() получается список производителей из хранилища и в случае успеха возвращается экземпляр ViewViewComponentResult (в его имени нет опечатки), где в качестве модели представления применяется список производителей. Если вызов для получения записей Make завершается неудачей, тогда производится возврат экземпляра ContentViewComponentResult с сообщением об ошибке. Модифицируйте
