Для обработки запроса каждая страница может использовать методы OnGet/OnPost/OnPut и так далее, то есть такие методы, которые предназначены для определенного вида запросов. Однако что если нам необходимо определить на странице для разных ситуаций несколько методов для обработки запроса одного и того же типа запросов (GET или POST)? В этом случае мы можем добавить в код страницы дополнительные обработчики запросов.
Например, пусть в проекте определен класс Person, который представляет данные:
И пусть в проекте есть страница Razor Person.cshtml и связанный с ней файл кода Person.cshtml.cs .
Пусть Person.cshtml.cs содержит следующее определение класса PersonModel:
Класс содержит некоторые начальные данные в переменной people — список объектов Person. При стандартном get-запросе в свойство DisplayedPeople передается весь этот список.
И также определены два метода — обработчики для фильтрации списка по имени и возрасту объекта Person. Так как оба этих обработчики будут также обрабатывать запросы get, то их название начинается с префикса OnGet .
На странице Person.cshtml выводится переданный из PersonModel список:
И при обычном запросе к странице сработает метод OnGet, поэтому на страницу будет выведен полный список:
Теперь обратимся к конкретному обработчику. Для этого в строку запроса передается параметр "handler" с указанием имени обработчика. Причем именем обработчика считается та часть названия метода, которая идет после префикса OnGet :
В данном случае обращение идет к обработчику OnGetByName. Поскольку он принимает параметр name, то через строку запроса для этого параметра передается значение: http://localhost:56288/Person?handler=ByName&name=Tom .
Передача обработчика через параметр маршрута
Не всегда может устроить добавление названия обработчика через строку запроса, наподобие ?handler=ByName . В этом случае можно передать название обработчика через параметр маршрута. Для этого изменим код страницы Person.cshtml:
Вопросительный знак после названия параметра "" указывает, что данный параметр является необязательным. И в этом случае можно просто указать в url последним сегментом название обработчика:
Обработка форм и запросов POST
Подобным образом мы можем использовать обработчики для для обработки запросов POST. Но кроме того тег-хелперов форм мы можем задавать явным образом нужный обработчик с помощью параметра asp-page-handler . Например, изменим код PersonModel:
Обработчик OnPostGreaterThan находит пользователей, у которых возраст больше определенного, а обработчик OnPostLessThan, наоборот, находит пользователей, у которых возраст меньше, чем определенный.
Изменим код страницы Person.cshtml:
На странице определена форма, но в зависимости от того, на какую кнопку мы нажмем, введенное значение будет улетать тому или иному обработчику.
Теперь, когда вы увидели, что собой представляет жизненный цикл страницы, и узнали, каким образом в странице содержатся элементы управления, не помешает указать, что экземпляр самой страницы тоже создается в виде объекта элемента управления. В действительности все веб-формы фактически являются экземплярами класса Page из ASP.NET, который находится в пространстве имен System.Web.UI.
Вы наверняка уже догадались об этом, заметив, что каждый класс отделенного кода явно наследуется от System.Web.UI.Page. Это означает, что каждая создаваемая веб-форма сразу же получает огромный объем функциональности, такой как уже встречавшийся ранее метод FindControl() и свойство IsPostBack. Помимо этого, наследование от Page также еще предоставляет коду доступ к следующим чрезвычайно полезным свойствам:
Многие из этих свойств соответствуют внутренним объектам, которые можно было использовать в классических веб-страницах ASP. Однако в классической версии ASP доступ к этой функциональной возможности получался с помощью встроенных объектов, которые были доступны всегда. В ASP.NET каждый из этих встроенных объектов фактически соответствует свойству Page, которое предоставляет экземпляр полнофункционального класса.
Более подробно об этих объектах рассказывается в последующих разделах.
Объекты Session, Application и Cache
Объект Session является экземпляром класса System.Web.SessionState.HttpSessionState. Он предназначен для хранения любого типа пользовательских данных, который должен постоянно существовать между запросами веб-страниц. Объект Session предоставляет словарный доступ к набору пар "имя-значение", представляющему пользовательские данные для этого сеанса. Состояние сеанса часто применяется для обслуживания информации наподобие имени и идентификатора пользователя, покупательской тележки либо других элементов, удаляемых, когда пользователь уже не посещает страницы веб-сайта.
Объект Application является экземпляром класса System.Web.HttpApplicationState. Подобно объекту Session, он тоже представляет собой словарь данных типа "имя-значение". Однако эти данные являются глобальными для всего приложения.
Что касается объекта Cache, то он является экземпляром класса System.Web.Caching.Cache. В нем также хранится глобальная информация, но он предлагает более масштабируемый механизм хранения, поскольку ASP.NET может удалять объекты в случае нехватки памяти сервера. Как и другие наборы состояний, это, по сути, коллекция объектов "имя-значение", однако здесь для каждого элемента можно также устанавливать специализированные политики истечения срока и определять зависимости.
Выбор способа реализации управления состоянием является одной из ключевых задач разработки веб-приложения.
Объект Request
Объект Request является экземпляром класса System.Web.HttpRequest. Этот объект представляет значения и свойства HTTP-запроса, который привел к загрузке страницы. В нем содержатся все параметры, касающиеся URL, а также все остальные данные, которые были отправлены клиентом. Большая часть из предоставляемой объектом Request информации заключена в оболочку абстракций более высокого уровня (например, в оболочку модели веб-элементов управления ASP.NET), поэтому она даже и близко не так важна, как это было в классической ASP-разработке.
Тем не менее, объект Request все равно может использоваться, например, для выяснения того, каким браузером пользуется клиент, или же для создания cookie-наборов и последующего изучения их содержимого.
В таблице ниже перечислены некоторые наиболее часто применяемые свойства объекта Request:
| Свойство | Описание |
|---|---|
| AnonymousID | Уникальным образом идентифицирует текущего пользователя, если был включен анонимный доступ. |
| ApplicationPath и PhysicalApplicationPath | ApplicationPath извлекает информацию о месте размещения виртуального каталога приложения ASP.NET (URL-адрес), a PhysicalPath — о месте размещения его "реального"каталога |
| Browser | Предоставляет ссылку на объект HttpBrowserCapabilities, в котором содержатся свойства, описывающие различные функциональные возможности браузера, наподобие наличия в нем поддержки для элементов управления ActiveX, cookie-наборов, сценариев VBScript и фреймов |
| ClientCertificate | Объект HttpClientCertificate, предоставляющий сертификат безопасности для текущего запроса, если таковой существует |
| Cookies | Предоставляет коллекцию cookie-наборов, отправляемых с этим запросом |
| FilePath и CurrentExecutionFilePath | Возвращают реальный путь к файлу (относительно сервера) для выполняемой в данный момент страницы. FilePath представляет страницу, запустившую процесс выполнения. Это то же самое, что и CurrentExecutionFilePath, если вы не переместили пользователя на новую страницу без перенаправления (например, с помощью метода Server.Transfer()), в случае чего CurrentExecutionFilePath отражает новую страницу, a FilePath определяет исходную страницу |
| Form | Представляет коллекцию переменных формы, обратно отправляемых странице. В большинстве случаев вместо использования данной коллекции вы будете извлекать эту информацию из свойств элемента управления |
| Headers и ServerVariables | Предоставляют словарную коллекцию HTTP-заголовков и серверных переменных с индексацией по имени. Эти коллекции по большей части состоят из низкоуровневой информации, которая отправлялась браузером вместе с веб-запросом (например, информации о типе браузера, поддерживаемых им функциональных возможностях, установленных языковых параметрах, удостоверениях, используемых для аутентификации данных, и т.д.). Обычно эту информацию гораздо легче получить из других свойств объекта HttpRequest или высокоуровневых классов ASP.NET |
| IsAuthenticated и IsSecureConnection | Возвращают true в случае успешной аутентификации пользователя и подключения пользователя по протоколу защищенных сокетов (Secure Sockets Layer — SSL) |
| IsLocal | Возвращает true, если пользователь запрашивает страницу с локального компьютера |
| QueryString | Предоставляет параметры, переданные в строке запроса |
| Url и UrlReferrer | Выдают объект Uri, представляющий текущий адрес страницы и страницу, с которой переходит пользователь (предыдущую страницу, содержащую ссылку на данную страницу) |
| UserAgent | Строка, представляющая тип браузера. Internet Explorer предоставляет для этого свойства значение MSIE. ASP.NET использует эту информацию для выяснения того, о браузере какого типа идет речь, и, следовательно, для определения, какие функциональные возможности этот браузер должен поддерживать (такие как cookie-наборы, сценарии JavaScript и т.д.). Это, в свою очередь, может влиять на способ визуализации веб-элементов управления. |
| UserHostAddress и UserHostName | Извлекают информацию об IP-адресе и DNS-имени удаленного клиента. К этой информации также можно получать доступ и через коллекцию ServerVariables. Однако из-за трансляции сетевых адресов (Network Address Translation — NAT) она не всегда бывает значимой. В зависимости от способа подключения к Интернету, многие клиенты могут использовать совместно один и тот же IP-адрес (например, IP-адрес шлюзового компьютера). Помимо этого, IP-адрес также еще может и меняться после выполнения нескольких запросов |
| UserLanguages | Предоставляет отсортированный строковый массив, в котором перечислены языковые предпочтения клиента. Может быть полезно при создании многоязычных страниц |
Объект Response
Объект Response является экземпляром класса System.Web.HttpResponse и представляет ответ веб-сервера на запрос клиента. При классической ASP-разработке объект Response был единственным способом программной отправки HTML-текста клиенту.
Теперь серверные элементы управления содержат вложенные объектно-ориентированные методы для выполнения визуализации самих себя. От разработчика требуется всего лишь установить значения их свойств. Поэтому объект Response даже близко не играет такой центральной роли, как раньше.
В следующей таблице перечислены некоторые наиболее часто применяемые члены класса HttpResponse:
| Метод или свойство | Описание |
|---|---|
| BufferOutput | Когда это свойство установлено в true (значение по умолчанию), страница не отправляется клиенту до тех пор, пока не будет визуализирована и готова к отправке полностью, вместо того, чтобы отправляться по частям. В некоторых специфических сценариях имеет смысл устанавливать это свойство в false. Наиболее очевидным примером является ситуация, когда клиент загружает большой файл. Если свойство BufferOutput установлено в false, клиент увидит диалоговое окно Save (Сохранить) и сможет выбрать имя файла, прежде чем этот файл будет загружен полностью |
| Cache | Это свойство ссылается на объект HttpCachePolicy, который позволяет конфигурировать кэширование вывода |
| Cookies | Это свойство предоставляет доступ к коллекции cookie-наборов, отправляемых вместе с ответом. Его можно использовать для добавления дополнительных cookie-наборов |
| Expires и ExpiresAbsolute | Эти свойства можно использовать при кэшировании визуализируемого HTML-кода страницы, улучшающем показатели производительности при последующих запросах |
| IsClientConnected | Это булевское значение, показывающее, подключен ли клиент к серверу. Если он уже не подключен, может потребоваться остановить какую-нибудь длинную операцию |
| Redirect() | Этот метод заставляет браузер запросить другой URL-адрес, который указывает на новую страницу веб-приложения или на другой веб-сайт |
| RedirectPermanent() | Этот метод перенаправляет браузер на новый URL-адрес, во многом подобно методу Redirect(). Разница в том, что он использует код состояния HTTP 301 (который указывает на то, что страница была перемещена навсегда), а не 302 (который указывает на то, что страница была перемещена временно) |
| RedirectToRoute() и RedirectToRoutePermanent() | Эти методы похожи на методы Redirect() и RedirectPermanent(). Единственное отличие в том, что они используют маршрут (зарегистрированный шаблон URL, который не отображается непосредственно на страницу) |
| Transfer() | Этот метод сообщает ASP.NET прекратить обработку текущей страницы и перейти к новой (указанной) странице с веб-формой. При этом не требуются полный цикл отправки и уведомление браузера и пользователя веб-приложения |
| TransferRequest() | Этот метод похож на Transfer(), но позволяет переносить пользователя на страницу другого типа. Например, его можно применять для отправки пользователя с веб-формы ASP.NET на HTML-страницу. Когда он используется, в действие приводится весь конвейер IIS для обработки нового ресурса, вместе со всеми соответствующими модулями HTTP. Но с методом TransferRequest() связан ряд существенных ограничений. Для его применения должен использоваться веб-сервер IIS 7 в интегрированном режиме. Кроме того, понадобится освободить состояние сеанса (если оно было получено) для предотвращения длительных задержек |
| ContentType | Это свойство представляет заголовок, указывающий браузеру, содержимое какого типа он должен получить. Обычно в веб-формах ASP.NET, как и во всех веб-страницах, используется содержимое типа text/html (текст вперемешку с HTML). Однако в принципе может быть создан специальный обработчик HTTP, обслуживающий содержимое других типов |
| OutputStream | Это свойство представляет данные, отправляемые браузеру в виде потока низкоуровневых байтов. Его можно использовать для подключения к модели потоков .NET |
| Write() | Этот метод позволяет записывать текст прямо в поток ответа. Обычно вместо него лучше применять модель элементов управления и позволять элементам управления генерировать собственную HTML-разметку. При попытке использовать метод Response.Write() вместе с моделью элементов управления разработчик лишается возможности решать, где именно на странице должен размещаться текст. Однако метод Response.Write() важен в ситуациях, когда элементы управления, генерирующие собственное HTML-представление, должны быть построены с нуля |
| BinaryWrite() и WriteFile() | Эти методы позволяют брать двоичное содержимое из массива байтов или файла и записывать его прямо в поток ответа. Использовать их вместе с серверными элементами управления не имеет смысла, но они могут быть очень полезны при создании специального обработчика HTTP. Например, можно создать HTTP-обработчик, считывающий данные для PDF-документа из записи в базе данных и записывающий их непосредственно в поток ответа с помощью метода BinaryWrite(). На стороне клиента конечный результат будет выглядеть точно так же, как и если бы пользователь загружал статический PDF-файл. При выполнении записи отличного от HTML содержимого не забывайте установить соответствующее значение для свойства ContentType |
Перемещение между страницами
Самой важной функцией класса HttpResponse является предоставление небольшого набора методов, которые позволяют переходить с одной страницы на другую. Наиболее универсальным из них является метод Redirect(), который позволяет перенаправлять пользователя на другую страницу. Ниже приведен пример его применения:
Метод Redirect() требует полного цикла отправки. По сути, он отправляет браузеру сообщение, которое заставляет его запросить новую страницу.
Метод Redirect() имеет перегруженную версию, которая принимает во втором параметре булевское значение. Это значение указывает, должен ли код страницы продолжить выполнение. По умолчанию, несмотря на то, что Redirect() перенаправляет пользователя и закрывает соединение, любой оставшийся код в методе по-прежнему будет выполняться вместе с остальными событиями страницы. Это позволяет при необходимости провести очистку. Но если во втором параметре передается значение true, ASP.NET немедленно прекратит обработку страницы, что потенциально сокращает рабочую нагрузку веб-сервера.
Если нужно переместить пользователя на другую веб-форму внутри того же самого веб-приложения, можно воспользоваться более быстрым подходом с помощью метода Server.Transfer(). Однако этот метод обладает некоторыми особенностями. Из-за того, что перенаправление происходит на стороне сервера, в окне клиентского веб-браузера остается исходный URL-адрес. По сути, у браузера нет никакой возможности узнать, что в действительности он отображает уже другую страницу. Это ограничение приводит к возникновению проблем, когда клиент обновляет страницу или устанавливает на ней закладку.
Кроме того, метод Server.Transfer() не умеет передавать управление отличной от ASP.NET странице или веб-странице, находящейся в другом веб-приложении или на другом веб-сайте.
Для перехода с одной страницы на другую доступен еще один прием — . Он позволяет создавать страницу, которая отправляет себя другой странице, что дает возможность передать всю информацию состояния представления и содержимое любых элементов управления.
В ASP.NET 4 в классе HttpResponse появился еще один метод для перенаправления пользователя — RedirectPermanent() . Этот метод делает то же самое, что и Redirect(), т.е. отправляет браузеру сообщение о перенаправлении, указывающее на необходимость запроса новой страницы. Однако вместо кода состояния HTTP 302 (временное перенаправление) он использует код 301 (который обозначает постоянное перенаправление). Для веб-браузеров это отличие роли не играет, но для поисковых систем оно является очень важным. Когда поисковый робот исследует веб-сайт и получает код состояния 301, он обновляет каталог своей поисковой системы, занося в него информацию о новом URL-адресе.
Это значит, что методы Redirect() и RedirectPermanent() должны использоваться очень разными способами. Метод Redirect() необходимо применять для обеспечения обычной навигации и управления потоком выполнения в приложении (например, при прохождении пользователем какого-то процесса проверки), а метод RedirectPermanent() — при запросе старого URL-адреса, который поддерживался ранее, но больше не используется.
Обычно метод Redirect() будет вызываться где-то в коде веб-формы, в то время как метод RedirectPermanent() — в коде приложения, а точнее в методе Application_BeginRequest() внутри файла global.asax. Это позволит управлять всеми постоянными перенаправлениями в одном месте, не сохраняя заглушки для старых страниц. Ниже приведен пример:
Объект Server
Объект Server является экземпляром класса System.Web.HttpServerUtility и предоставляет разнообразные вспомогательные методы и свойства, которые перечислены в таблице:
| Метод или свойство | Описание |
|---|---|
| MachineName | Свойство, представляющее имя компьютера, на котором запускается страница. Это имя веб-сервера, используемого компьютером с целью его идентификации для остальной части сети |
| GetLastError() | Извлекает объект исключения для самой поздней ошибки (или ссылку null, если таковая не существует). Эта ошибка должна была произойти во время обработки текущего запроса и не была обработана. Чаще всего используется в обработчике событий приложения, проверяющем сбойные ситуации |
| HtmlEncode() и HtmlDecode() | Заменяет обычную строку строкой допустимых символов HTML (и наоборот) |
| UrlEncode() и UrlDecode() | Заменяет обычную строку строкой допустимых символов URL (и наоборот) |
| MapPath() | Возвращает физический путь к файлу, соответствующий определенному виртуальному пути к файлу на веб-сервере. Вызов MapPath() с указанием / возвращает физический путь к корневому каталогу веб-приложения. Также поддерживает пути, содержащие символ тильды ( |
), который представляет корневой каталог веб-сайта (например,
/homepage.aspx)
Метод Transfer() является наиболее быстрым способом перемещения пользователя на другую страницу приложения. При использовании этого метода не происходит полного цикла отправки. Вместо этого механизм ASP.NET просто загружает новую страницу и начинает ее обработку. В результате URL, отображаемый в браузере клиента, не меняется.
MapPath() представляет собой еще один полезный метод объекта Server. Например, предположим, что вы хотите загрузить из текущего виртуального каталога файл по имени info.txt. Вместо того чтобы жестко кодировать путь, вы можете воспользоваться методом Server.MapPath() и с его помощью преобразовать относительный путь к своему веб-приложению в полный физический путь.
Кодирование HTML и URL
Класс Server также содержит методы, преобразующие обычные строки в представление, которое может безопасно использоваться как часть URL или отображаться на веб-странице. Например, предположим, что вы собираетесь отобразить на веб-странице следующий текст:
При попытке записи этой информации на странице или ее помещении в элемент управления получится следующее:
не появится, к тому же браузер интерпретирует его как включение абзаца. С целью обхода такого автоматического поведения потребуется преобразовать потенциальные проблемные значения в специальные HTML-эквиваленты. Например, отображаются в виде текста, а не интерпретируются как код HTML.
На рисунке можно видеть новые записи в журнале:
Выполните следующие действия, чтобы приступить к работе с данными с помощью Entity Framework Core в веб-приложении ASP.NET Core. Follow these steps to start working with data using Entity Framework Core in your ASP.NET Core Web App.
Выполните инструкции из этого видео, чтобы добавить данные в приложение ASP.NET Core. Watch this video and follow along to add data to your first ASP.NET Core app.
Открытие проекта Open your project
Если вы выполняете инструкции из этих видео, откройте проект веб-приложения, созданный в предыдущем разделе. If you’re following along with these videos, open the Web Application project you created in the previous section. Если практический пример вы начали выполнять только здесь, необходимо создать новый проект и выбрать Веб-приложение ASP.NET, а затем Веб-приложение. If you’re starting here, you need to create a new project and choose ASP.NET Web Application and then Web Application. Оставьте для остальных параметров значения по умолчанию. Leave the rest of the options as defaults.
Добавление модели Add your model
Первое, что необходимо сделать, чтобы работать с данными в приложении ASP.NET Core — описать, как должны выглядеть данные. The first thing you need to do to work with data in your ASP.NET Core application is to describe what the data should look like. Мы называем это созданием модели вещей, связанных с проблемой, которую мы пытаемся решить. We call that creating a model of the things involved in the problem we’re trying to solve. В реальных приложениях мы добавим в эти модели пользовательскую бизнес-логику, чтобы они могли вести себя определенным образом и автоматизировать для нас задачи. In real world applications, we’ll add custom business logic to these models so they can behave in certain ways and automate tasks for us. В этом примере мы создадим простую систему для отслеживания настольных игр. For this sample, we’re going to create a simple system for tracking board games. Нам нужен класс, представляющий игры и включающий в себя некоторые свойства, которые мы хотим записать об этой игре, в частности, сколько игроков она может поддерживать. We need a class that represents a game, and includes some properties that we might want to record about that game, like how many players it can support. Этот класс будет отправлен в новую папку, которую мы создадим в корневом каталоге веб-проекта с именем Models. This class will go into a new folder we’ll create in the root of the web project, called Models.
Создание страниц для управления библиотекой игр Create the pages to manage your game library
Теперь мы готовы к созданию страниц, которые будем использовать для управления библиотекой игр. Now we’re ready to create the pages we’ll use to manage our library of games. Это может звучать устрашающе, но на самом деле это совсем просто. This might sound daunting but it’s actually amazingly easy. Сначала необходимо решить, где в нашем приложении мы пропишем эту функцию. First we need to decide where in our app this functionality should live. Откройте в веб-проекте папку Pages и добавьте новую папку. Open the Pages folder in the web project and add a new folder there. Назовите ее Games. Call it Games.
Теперь щелкните правой кнопкой папку Games и выберите Добавить > Создать шаблонный элемент. Now right click on Games and choose Add > New Scaffolded Item. Выберите Razor Pages на основе параметра Entity Framework (CRUD) . Choose the Razor Pages using Entity Framework (CRUD) option. CRUD (Create, Read, Update, Delete) означает "создание, чтение, обновление и удаление". Этот шаблон создаст страницы для каждой из этих операций (в том числе страницу "список всех" и страницу "просмотреть подробности об элементе"). CRUD stands for "Create, Read, Update, Delete" and this template will create pages for each of these operations (including a "list all" page and a "view details of one item" page).
Выберите класс модели игр и используйте значок "+", чтобы добавить новый класс контекста данных. Select your Game model class and use the ‘+’ icon to add a new Data context class. Присвойте обработчику события имя AppDbContext . Name it AppDbContext . Оставьте остальные значения по умолчанию и нажмите кнопку Добавить. Leave the rest as defaults and click Add.
Вы увидите, что следующие Razor Pages добавлены в папку Games: You will see the following Razor Pages added to your Games folder:
- Create.cshtml Create.cshtml
- DELETE.cshtml Delete.cshtml
- Details.cshtml Details.cshtml
- Edit.cshtml Edit.cshtml
- Index.cshtml Index.cshtml
Наряду с добавлением страниц в папку Games, операция формирования шаблонов добавит код в классStartup.cs. In addition to adding pages in the Games folder, the scaffolding operation added code to my Startup.cs class. Просмотрев в этом классе метод ConfigureServices , вы увидите, что был добавлен следующий код. Looking in the ConfigureServices method in this class you will see this code has been added:
Вы также увидите, что в файл проекта appsettings.json была добавлена строка подключения AppDbContext . You’ll also find the AppDbContext connection string has been added to the project’s appsettings.json file.
Если запустить приложение сейчас, это может привести к сбою, поскольку база данных ещё не создана. If you run the app now, it may fail because no database has been created, yet. При необходимости вы можете настроить приложение на автоматическое создание базы данных, добавив код в Program.cs. You can configure the app to automatically create the database if needed by adding some code to Program.cs:
Чтобы разрешить имя TypeName в приведенном выше коде, добавьте следующие операторы using в Program.cs в конце существующего блока операторов using: To resolve the typenames in the preceding code, add the following using statements to Program.cs at the end of the existing block of using statements:
Не забудьте указать имя проекта вместо WebApplication1 в коде. Be sure to use your project name instead of WebApplication1 in your code.
Большая часть кода — это только обработка ошибок, а также предоставление доступа к EF Core AppDbContext до начала работы приложения. Most of the code is just for error handling and to provide access to the EF Core AppDbContext before the app is running. Важная строка — та, в которой указано context.Database.EnsureCreated() , благодаря чему будет создана база данных, если она еще не существует. The important line is the one that says context.Database.EnsureCreated() , which will create the database if it doesn’t already exist. Теперь приложение готово к запуску. Now the app is ready to run.
Тестирование приложения Test it out
Запустите приложение и перейдите к /Games адресной строке. Run the application and navigate to /Games in the address bar. Вы увидите страницу с пустым списком. You will see an empty list page. Щелкните Новый, чтобы добавить новый список Game в коллекцию. Click Create New to add a new Game to the collection. Заполните форму и нажмите Создать. Fill in the form and click Create. Вы должны увидеть его в представлении списка. You should see it in the list view. Щелкните Подробности, чтобы просмотреть сведения об отдельной записи. Click on Details to see the details of a single record.
Добавьте еще одну запись. Add another record. Можно щелкнуть Правка для изменения сведений о записи или Удалить, чтобы удалить ее, после чего вам будет предложено подтвердить действие перед удалением записи. You can click Edit to change the details of a record, or Delete to remove it, which will prompt you to confirm before it actually deletes the record.
Это все, что нужно для начала работы с данными в приложении ASP.NET Core с использованием EF Core и Visual Studio 2019. That’s all it took to start working with data in an ASP.NET Core app using EF Core and Visual Studio 2019.
Следующие шаги Next steps
В следующем видео вы узнаете, как добавить поддержку веб-API в приложение. In the next video, you’ll learn how to add web API support to your app.
