C# ASP.NET Core. Уровень 2. Cоздание веб-сайтов и порталов продвинутый уровень


Содержание

Веб-сайты ASP.NET

Научившись создавать цельные веб-страницы, программист начинает задумываться об общей картине — т.е. о группировании большого числа вебстраниц в единый логически связанный веб-сайт. В разделе «Основы ASP.NET» рассматривались некоторые основы этого процесса, такие как управление состоянием при переходе пользователя от одной страницы к другой и использование отдельных компонентов для выноса кода доступа к данных за пределы веб-страниц, чтобы они были доступны тогда, когда в них возникает потребность.

Однако программист сталкивается также с такими задачами, как обеспечение логической связности всех страниц и упрощение навигации по вебсайту. В этой части мы рассмотрим вопросы, которые становятся актуальными, когда вы перестаете думать об отдельных страницах и переходите к планированию веб-приложения в целом.

Вначале мы рассмотрим пользовательские элементы управления, которые дают возможность применять блок интерфейса пользователя в нескольких страницах. Затем вы познакомитесь с еще двумя инструментами: темами, которые позволяют автоматически устанавливать свойства элемента управления, и мастер-страницами, которые позволяют многократно использовать один шаблон для стандартизации компоновки и содержимого во множестве страниц. Все вместе эти три инструмента обеспечивают, чтобы веб-приложение выглядело как логически связанное единое целое.

Также будет рассмотрена тема, связанная с предыдущими: применение карт сайтов и элементов управления навигацией для предоставления пользователям возможности перемещения по веб-сайту. И, наконец, вы научитесь переносить свои веб-приложения в производственную среду, перемещая их из компьютера разработки <или тестового сервера) на полноценный веб-сервер, на котором функционирует IIS.

Так же будет показано, как можно расширять веб-страницы с помощью дополнительных технологий: специальных элементов управления, GDI+ для создания графики вручную, JavaScript и Ajax и средства Web Parts, которое позволяет легко создавать веб-порталы.

Порядок выполнения лабораторной работы. Создание веб-приложений с помощью ASP.NET

Лабораторная работа №9

Создание веб-приложений с помощью ASP.NET.

Цель работы: ознакомление с основными этапами разработки веб-приложений на основе ASP.NET в среде Microsoft Visual Studio.NET. Изучение структуры проекта ASP.NET Web Application.

ASP.NET файл является текстовым файлом и может содержать коды HTML, XML и языков сценариев. Коды последних выполняются на веб-сервере. Файл ASP.NET имеет специальное расширение » .aspx «.

Порядок работы ASP.NET выглядит следующим образом:

  • Когда веб-браузер запрашивает файл ASP.NET, веб-сервер IIS перенаправляет запрос модулю ASP.NET на сервере.
  • Модуль ASP.NET читает файл построчно и выполняет, коды сценариев, содержащиеся в файле.
  • Веб-браузеру возвращается обратно файл ASP.NET, но уже в виде обычного HTML документа.

Любая страница ASP.NET представлена классом, производным от класса System.Web.UI, который определяет свойства, методы и события, общие для всех страниц, предназначенных для обработки средой ASP.NET

Наиболее важные свойства этого объекта приведены в таблице ниже:

Свойство Описание
Application Возвращает объект HttpApplicationState
Cache Возвращает объект Cache, в котором хранятся данные приложения, в т.ч. и самой страницы
IsPostBack Возвращает значение, определяющее, была ли страница загружена клиентом впервый раз, или загружена повторно в ответ на запрос клиента
Request Возвращает объект HttpRequest, используемый для получения информации о входящем запросе HTTP
Response Возвращает объект HttpResponse, используемые для формирования ответа сервера клиенту
Server Возвращает объект HttpServerUtility
Session Возвращает объект System.Web.SessionState.HttpSessionState, с помощью которого получается информация о текущем сеансе HTTP

Такое построение проекта позволяет хранить отдельно код представления для генерации HTML кода (в файле *.aspx ) от программной логики (в файле *.aspx.cs ), что во многих случаях существенно упрощает разработку сложных веб-приложений.

Порядок выполнения лабораторной работы

Для работы с примерами, приводимыми в данной лабораторной работе, потребуется установка среды разработки Microsoft Visual Studio 2005+ и веб-сервера IIS 5+ (Internet Information Server).

  1. Cоздание нового проекта в среде Microsoft Visual Studio с использованием шаблона ASP.NET Web Application:

Каждое из веб-приложений для IIS должно размещаться в своем виртуальном каталоге, которому соответствует физический каталог на диске. Для создания виртуального каталога необходимо:

    1. открыть оснастку Microsoft Internet Information Services ( Пуск > Панель управления > Администрирование > Internet Information Services );
    2. раскрыть ветку «Веб-узлы» и, перейдя в «Веб-узел по умолчанию», создать новый виртуальный каталог:
    1. в свойствах созданного виртуального каталога выбрать закладку «Документы» и добавить в список документов, используемых по умолчанию, документ Default.aspx.

После завершения создания проекта, он будет содержать файлы Default.aspx, Default.aspx.cs и Default.asp.designer.cs.

Первый из них будет содержать примерно следующий код:

ASP.NET Core Developer

ASP.NET Core-разработчик — специалист в области разработки веб-приложений с использованием технологии от компании Microsoft — ASP.NET Core.

ASP.NET Core — это фреймворк для создания серверной части современных веб-сайтов, позволяющий определить комплексную архитектуру программы, обладающий целым рядом уникальных возможностей и преимуществ в сравнении с другими технологиями подобного рода прочих платформ.

В основе ASP.NET Core лежит успевший себя зарекомендовать с хорошей стороны язык программироания C#. В распоряжении ASP.NET Core-программиста будут такие мощные инструменты, как LINQ, лямбда-выражения и множество различного «синтаксического сахара», в значительной мере упрощающего процесс разработки — в основном за счет увеличения скорости написания кода и меньших затратах на поддержку. Также при желании разработчик легко сможет компонировать другие языки .NET группы, а именно: Visual Basic и F#.

Приставка Core говорит о том, что фреймворк исполнен на базе самой новой платформы, релиз которой ознаменовал переход к новой эре разработки под эгидой Microsoft. Речь идет о стандарте .NET Core.

.NET Core — это новый стандарт разработки, пришедший на смену .NET Framework. И хотя у .NET Core нет цели вытеснить .NET Framework с рынка программного обеспечения, многие специалисты сразу же заметили в Core-версии большой потенциал и начали использовать его в своей работе.

Что же уникального привносит Core-технология в сравнении с .NET Framework? Во-первых (и самое главное) — это кросс-платформенность. Теперь разработчик сможет запустить .NET-приложение не только под Windows, но и под Linux или даже MacOS. Во-вторых, это скорость работы программ, которая, в сравнении с предыдущей версией, стала несколько выше. Третье преимущество — полностью открытый исходный код платформы, благодаря чему каждый желающий сможет приобщиться к развитию или изучить особенности работы новой технологии.

Одностраничные приложения: создание современных адаптивных веб-приложений с помощью ASP.NET

Продукты и технологии:

Single-Page Applications (SPA), ASP.NET Web API, Knockout.js, Ember.js, AJAX и HTML5

В статье рассматриваются:

  • создание уровня сервисов и веб-клиента AJAX для приложения-примера;
  • шаблоны MVC и MVVM;
  • связывание с данными;
  • создание веб-клиента с применением Knockout.js;
  • создание веб-клиента с применением Ember.js.

Одностраничные приложения (Single-Page Applications, SPA) — это веб-приложения, которые загружают одну HTML-страницу и динамически обновляют ее при взаимодействии с пользователем.

SPA используют AJAX и HTML5 для создания гибких и адаптивных веб-приложений без постоянных перезагрузок страницы. Однако это означает, что большая часть работы возлагается на клиентскую сторону, а именно на JavaScript-код. Разработчику для традиционной ASP.NET может быть трудно совершить такой кульбит. К счастью, существует множество JavaScript-инфраструктур с открытым исходным кодом, которые облегчают создание SPA.

В этой статье я пошагово пройду процесс создания простого SPA-приложения. Попутно вы ознакомитесь с некоторыми фундаментальными концепциями создания SPA, в том числе с шаблонами Model-View-Controller (MVC) и Model-View-ViewModel (MVVM), связыванием с данными и маршрутизацией (routing).

О приложении-примере

Я создал приложение-пример для операций с простой базой данных по фильмам (рис. 1). В крайнем слева столбце страницы отображается список жанров. Выбор жанра приводит к появлению списка соответствующих фильмов. Кнопка Edit рядом с записью позволяет изменять эту запись. После редактирования можно щелкнуть кнопку Save для передачи обновления на сервер или кнопку Cancel для отмены изменений.

Рис. 1. SPA-приложение для базы данных по фильмам

Я создал две версии этого приложения: одна из них использует библиотеку Knockout.js, а другая — библиотеку Ember.js. Эти две библиотеки основаны на разных подходах, поэтому будет весьма поучительно сравнить их. В обоих случаях клиентское приложение не требовало более 150 строк JavaScript-кода. На серверной стороне я задействовал ASP.NET Web API, чтобы обслуживать JSON для клиента. Исходный код обеих версий вы найдете на github.com/MikeWasson/MoviesSPA.

(Примечание Я создавал приложение, используя RC-версию Visual Studio 2013. В RTM-версии некоторые вещи могли измениться, но они не должны повлиять на код.)

Обзор

В традиционном веб-приложении при каждом вызове сервера тот осуществляет рендеринг новой HTML-страницы. Это вызывает обновление страницы в браузере. Если вы когда-нибудь писали приложение Web Forms или PHP, этот жизненный цикл страниц должен быть знаком вам.

В SPA после загрузки первой страницы все взаимодействие с сервером происходит через AJAX-вызовы. Эти AJAX-вызовы возвращают данные (не разметку) — обычно в формате JSON. Приложение использует JSON-данные для динамического обновления страницы без ее перезагрузки. Рис. 2 иллюстрирует разницу между этими двумя подходами.

Рис. 2. Сравнение традиционного жизненного цикла страницы с жизненным циклом в SPA

Traditional Page Lifecycle Традиционный жизненный цикл страницы
Client Клиент
Page Reload Перезагрузка страницы
Server Сервер
Initial Request Начальный запрос
HTML HTML
Form POST Передача формы командой POST
SPA Lifecycle Жизненный цикл в SPA
AJAX AJAX
JSON JSON

Одно из преимуществ SPA очевидно: приложения более гибкие и адаптивные, свободные от рваного эффекта перезагрузки страницы и ее рендеринга заново. Другое преимущество может оказаться менее очевидным и касается того, как вы проектируете архитектуру веб-приложения. Отправка данных приложения как JSON обеспечивает разделение между презентационной частью (HTML-разметкой) и прикладной логикой (AJAX-запросы плюс JSON-ответы).

Это разделение упрощает проектирование и развитие каждого уровня. В SPA-приложении с тщательно продуманной архитектурой можно изменять HTML-разметку, не касаясь кода, который реализует прикладную логику (по крайней мере, в идеале). Вы увидите это на практике, когда мы будем обсуждать связывание с данными.

В чистом SPA все UI-взаимодействие происходит на клиентской стороне через JavaScript и CSS. После начальной загрузки страницы сервер действует исключительно как уровень сервисов. Клиенту нужно просто знать, какие HTTP-запросы он должен посылать. Ему не важно, как сервер реализует свою часть.

При такой архитектуре клиент и сервис независимы. Вы могли бы полностью заменить серверную часть, которая выполняет сервис, и, пока вы не изменяете API, вы никак не нарушите работу клиента. Верно и обратное: вы можете заменить все клиентское приложение, не изменяя уровень сервисов. Например, вы могли бы написать родной мобильный клиент, который использует этот сервис.

Создание проекта в Visual Studio

В Visual Studio 2013 есть один тип проекта ASP.NET Web Application. Мастер этого проекта позволяет выбрать ASP.NET-компоненты, которые будут включены в проект. Я начал с шаблона Empty, а затем добавил в проект ASP.NET Web API, установив флажок Web API в разделе Add folders and core references for, как показано на рис. 3.

Рис. 3. Создание нового ASP.NET-проекта в Visual Studio 2013

В новом проекте есть все библиотеки, необходимые для Web API, а также кое-какой конфигурационный код Web API. Я не вводил никаких зависимостей от Web Forms или ASP.NET MVC.

Обратите внимание на рис. 3, что Visual Studio 2013 включает шаблон Single Page Application. Этот шаблон устанавливает скелет SPA-приложения, основанный на Knockout.js. Он поддерживает вход с применением базы данных с информацией о членстве в группах или с помощью внешнего провайдера аутентификации. Я не стал использовать этот шаблон в своем приложении, потому что хотел показать более простой пример с нуля. Шаблон SPA — отличный ресурс, особенно если вам нужно добавить аутентификацию в приложение.

Создание уровня сервисов

Я использовал ASP.NET Web API, чтобы создать простой REST API для приложения. Не буду здесь вдаваться в детали Web API — подробности вы можете прочитать по ссылке asp.net/web-api.

Сначала я создал класс Movie, представляющий фильм. Этот класс делает две вещи:

  • сообщает Entity Framework (EF), как создавать таблицы базы данных для хранения информации о фильмах;
  • сообщает Web API, как форматировать полезные данные JSON.

Вы не обязаны использовать одну модель для обеих целей. Например, вам может понадобиться, чтобы схема базы данных отличалась от полезных данных JSON. В этом приложении я ничего не усложняю:

Затем я воспользовался технологией scaffolding в Visual Studio для создания контроллера Web API, который задействует EF в качестве уровня данных. Чтобы применить эту технологию, щелкните правой кнопкой мыши папку Controllers в Solution Explorer и выберите Add | New Scaffolded Item. В мастере Add Scaffold укажите Web API 2 Controller with actions, using Entity Framework, как показано на рис. 4.

Рис. 4. Добавление контроллера Web API

На рис. 5 приведен мастер Add Controller. Я присвоил контроллеру имя MoviesController. Имя имеет значение, так как URI для REST API основываются на имени контроллера. Я также установил флажок Use async controller actions, чтобы задействовать преимущества новой функциональности async в EF 6. Я выбрал класс Movie в качестве модели и указал New data context, чтобы создать новый контекст данных EF.

Рис. 5. Мастер Add Controller

Мастер добавляет два файла:

  • MoviesController.cs — определяет контроллер Web API, который реализует REST API для приложения;
  • MovieSPAContext.cs — это в основном склеивающий слой EF, который предоставляет методы для запроса нижележащей базы данных.

В табл. 1 показан REST API по умолчанию, создаваемый технологией scaffolding.

Табл. 1. REST API по умолчанию, созданный технологией scaffolding из Web API

HTTP-команда URI Описание
GET /api/movies Получить список всех фильмов
GET /api/movies/ Получить фильм с идентификатором, равным
PUT /api/movies/ Обновить фильм с идентификатором, равным
POST /api/movies Добавить новый фильм в базу данных
DELETE /api/movies/ Удалить фильм из базы данных

Значения в фигурных скобках являются заменителями для подстановки. Например, чтобы получить фильм с идентификатором, равным 5, URI должен выглядеть так: /api/movies/5.

Я расширил этот API, добавив метод, который находит все фильмы указанного жанра:

Клиент указывает жанр в строке запроса URI. Например, чтобы получить все фильмы жанра Drama, клиент посылает GET-запрос на /api/movies?genre=drama. Web API автоматически связывает параметр запроса с параметром genre в методе GetMoviesByGenre.

Создание веб-клиента

До сих пор я просто создавал REST API. Если вы отправите GET-запрос на /api/movies?genre=drama, исходный HTTP-ответ будет выглядеть так:

Теперь мне нужно написать клиентское приложение, которое делает с этим что-то осмысленное. Базовый рабочий процесс такой:

  • UI инициирует AJAX-запрос;
  • обновляем HTML для отображения полезных данных ответа;
  • обрабатываем AJAX-ошибки.

Вы могли закодировать все это вручную. Например, вот некоторый jQuery-код, который создает список названий фильмов:

В этом коде есть кое-какие проблемы. Он смешивает прикладную логику с презентационной и тесно связан с вашим HTML. Кроме того, писать его весьма утомительно. Вместо того чтобы сосредоточиться на приложении, вы тратите время на написание обработчиков событий и кода, манипулирующего DOM.

Решение заключается в том, чтобы использовать JavaScript-инфраструктуру. К счастью, их выбор довольно велик, и эти инфраструктуры имеют открытый исходный код. К некоторым из более популярных инфраструктур относятся Backbone, Angular, Ember, Knockout, Dojo и JavaScriptMVC. Большинство использует вариации шаблонов MVC или MVVM, поэтому будет полезно вкратце рассмотреть эти шаблоны.

Шаблоны MVC и MVVM

Корни шаблона MVC уходят в 80-е годы прошлого века и связаны с ранними графическими UI. Цель MVC — разбиение кода на три уровня со своими обязанностями (рис. 6). Вот что они делают:

  • модель представляет данные и бизнес-логику предметной области;
  • представление отображает модель;
  • контроллер принимает пользовательский ввод и обновляет модель.

Рис. 6. Шаблон MVC

View View
Controller Controller
Model Model
User Input Пользовательский ввод
Updates Обновления
Modifies Модифицирует

Более современная вариация MVC — шаблон MVVM (рис. 7). В шаблоне MVVM:

  • модель по-прежнему представляет данные предметной области;
  • модель представления — это абстрактное отражение представления;
  • представление отображает модель представления и посылает пользовательский ввод модели представления.

Рис. 7. Шаблон MVVM

View Model View Model

В JavaScript-инфраструктуре MVVM представлением является разметка, а моделью представления — код.

MVC имеет много вариаций, а литература по MVC зачастую противоречива и запутана. По-видимому, это и не удивительно для проектировочного шаблона, который начал свою жизнь со Smalltalk-76 и все еще применяется в современных веб-приложениях. Поэтому, хоть и хорошо знать теорию, главное — понимать конкретную инфраструктуру MVC, используемую вами.

Создание веб-клиента с применением Knockout.js

Для первой версии своего приложения я использовал библиотеку Knockout.js. Knockout следует шаблону MVVM, соединяя представление и модель представления через связывание с данными.

Чтобы создать привязки данных, вы добавляете к HTML-элементам специальный атрибут data-binding. Например, следующая разметка связывает элемент span со свойством genre в модели представления. Всякий раз, когда изменяется значение genre, Knockout автоматически обновляет HTML:

Привязки также могут работать в другом направлении, скажем, если пользователь вводит текст в поле, Knockout обновляет соответствующее свойство в модели представления.

Удобно, что связывание с данными осуществляется декларативно. Вам не требуется подключать модель представления к элементам HTML-страницы. Просто добавьте атрибут data-binding, и Knockout сделает остальное.

Я начал с создания HTML-страницы с базовой разметкой без связывания с данными, как показано на рис. 8.

Рис. 8. Начальная HTML-разметка

(Примечание Я использовал библиотеку Bootstrap для оформления внешнего вида приложения, поэтому в настоящем приложении уйма дополнительных элементов

Создание модели представления

Наблюдаемые объекты (observables) занимают центральное место в системе связывания с данными в Knockout. Наблюдаемым является объект, который хранит какое-то значение и может уведомлять подписчиков об изменении этого значения. Следующий код преобразует JSON-представление фильма в эквивалентный объект с наблюдаемыми полями:

На рис. 9 показана начальная реализация модели представления. Эта версия поддерживает только получение списка фильмов. Средства редактирования я добавлю позже. Модель представления содержит наблюдаемые свойства для списка фильмов, строку ошибки и текущий жанр.

Рис. 9. Модель представления

Заметьте, что фильмы находятся в observableArray. Как и подразумевает его имя, observableArray действует как массив, уведомляющий подписчиков об изменении своего содержимого.

Функция getByGenre выдает AJAX-запрос серверу на получение списка фильмов, а затем заполняет результатами массив self.movies.

При использовании REST API одна из самых хитрых частей — обработка асинхронной природы HTTP. jQuery-функция ajax возвращает объект, реализующий Promises API. Вы можете задействовать метод then объекта Promise, чтобы установить обратный вызов, инициируемый, когда AJAX-вызов завершается успешно, и еще один обратный вызов, запускаемый при неудачном AJAX-вызове:

Привязки данных

Теперь, когда у меня есть модель представления, я могу связать ее с HTML через привязки данных. Для полного списка жанров, который появляется на левой стороне экрана, я использую следующие привязки данных:

Атрибут data-bind содержит одно или более объявлений привязок, где каждая привязка имеет форму «привязка: выражение». В этом примере привязка foreach сообщает Knockout перебирать в цикле содержимое массива genres в модели представления. Для каждого элемента в массиве Knockout создает новый элемент
. Привязка text в присваивает text в span значение элемента массива, каковой в данном случае является названием жанра.

На данный момент щелчок названия жанра ни к чему не приводит, поэтому я добавляю привязку click для обработки событий щелчка:

Это связывает событие щелчка с функцией getByGenre в модели представления. Здесь нужно было использовать $parent, так как эта привязка осуществляется в контексте foreach. По умолчанию привязки в foreach ссылаются на текущий элемент в цикле.

Чтобы отобразить список фильмов, я добавил привязки в таблицу, как показано на рис. 10.

Рис. 10. Добавление привязок в таблицу для отображения списка фильмов

На рис. 10 привязка foreach перебирает в цикле массив объектов movie. Внутри foreach привязки text ссылаются на свойства текущего объекта.

Привязка visible в элементе

контролирует, визуализируется ли таблица. Таблица будет скрыта, если массив movies пуст.

Наконец, вот привязки для сообщения об ошибке и сообщения «No records found» (заметьте, что вы можете помещать в привязку сложные выражения):

Редактирование записей

Последняя часть этого приложения дает возможность пользователю редактировать записи в таблице. Для этого необходима следующая функциональность:

  • переключение между режимами просмотра (только текст) и редактирования (элементы управления вводом);
  • передача обновлений на сервер;
  • поддержка отмены изменений и восстановление исходных данных.

Чтобы отслеживать режим просмотра/редактирования, я добавил булев флаг в объект movie как наблюдаемое свойство:

Мне нужно было, чтобы таблица фильмов отображала текст, когда свойство editing равно false, но переключалась на элементы управления вводом, когда оно — true. Для этого я использовал Knockout-привязки if и ifnot, как показано на рис. 11. Синтаксис « » позволяет включать привязки if и ifnot без их размещения внутри элемента HTML-контейнера.

Рис. 11. Поддержка редактирования записей о фильмах

Привязка value задает значение элемента управления вводом. Это двухсторонняя привязка, поэтому, когда пользователь вводит что-то в текстовое поле или изменяет выбор в раскрывающемся списке, изменение автоматически распространяется на модель представления.

Я связал обработчики щелчка кнопок с функциями save, cancel и edit в модели представления.

Функция edit проста. Достаточно установить флаг editing в true:

Функции save и cancel немного посложнее. Для поддержки отмены мне нужен был какой-то способ кеширования исходного значения при редактировании. К счастью, Knockout упрощает расширение поведения наблюдаемых объектов. В коде на рис. 12 добавляется функция store в класс observable. Вызов функции store из observable придает этому классу две новые функции: revert и commit.

Рис. 12. Расширение ko.observable функциями revert и commit

Теперь я могу вызвать функцию store, чтобы добавить эту функциональность в модель:

Рис. 13 демонстрирует функции save и cancel в модели представления.

Рис. 13. Добавление функций save и cancel

Создание веб-клиента с применением Ember

Для сравнения я написал другую версию своего приложения, используя библиотеку Ember.js.

Ember-приложение начинает с таблицы маршрутизации (routing table), которая определяет навигацию пользователя в рамках приложения:

Первая строка кода создает Ember-приложение. Вызов Router.map создает три маршрута. Каждый маршрут соответствует URI или шаблону URI:

Для каждого маршрута вы создаете HTML-шаблон, используя библиотеку шаблонов Handlebars.

В Ember имеется шаблон верхнего уровня для всего приложения. Этот шаблон подвергается рендерингу для каждого маршрута. На рис. 14 показан шаблон application для моего приложения. Как видите, этот шаблон в основном является HTML-кодом, размещаемым в теге script с type=»text/x-handlebars». Шаблон содержит специальную разметку Handlebars в двойных фигурных скобках: << >>. Эта разметка служит той же цели, что и атрибут data-bind в Knockout. Например, <<#linkTo>> создает ссылку на маршрут.

Рис. 14. Шаблон Handlebars уровня приложения

Теперь допустим, что пользователь переходит к /#/about. Это активирует маршрут about. Ember сначала осуществляет рендеринг шаблона application верхнего уровня, затем шаблона about в <> шаблона application. Вот шаблон about:

На рис. 15 показано, как выполняется рендеринг шаблона about в шаблоне application.

Рис. 15. Рендеринг шаблона about


Поскольку у каждого маршрута свой URI, история браузера сохраняется. Пользователь может осуществлять навигацию кнопкой Back, а также обновлять страницу, не теряя контекст или закладку, и перезагружать ту же страницу.

Контроллеры и модели в Ember

В Ember каждый маршрут имеет модель и контроллер. Модель содержит данные предметной области. Контроллер действует как прокси для модели и хранит все данные состояния приложения для представления. (Это не совпадает с классическим определением MVC. В некоторых отношениях контроллер больше похож на модель представления.)

Вот как я определил модель movie:

Контроллер наследует от Ember.ObjectController (рис. 16).

Рис. 16. Контроллер Movie наследует от Ember.ObjectController

Здесь происходит кое-что интересное. Во-первых, я не указывал модель в классе контроллера. По умолчанию маршрут автоматически устанавливает модель в контроллере. Во-вторых, функции save и cancel используют средства транзакций, встроенные в класс DS.Model. Для отмены изменений просто вызовите функцию rollback модели.

Ember использует массу соглашений по именованию для подключения различных компонентов. Маршрут genres взаимодействует с GenresController, который выполняет рендеринг шаблона genres. По сути, Ember будет автоматически создавать объект GenresController, если вы его не определили. Однако вы можете переопределять все, что предлагается по умолчанию.

В своем приложении я сконфигурировал маршрут genres/movies на использование другого контроллера, реализовав точку подключения (hook) renderTemplate. Тем самым несколько маршрутов может использовать один и тот же контроллер (рис. 17).

Рис. 17. Несколько маршрутов могут иметь общий контроллер

Одна из приятных особенностей Ember в том, что многое можно делать с помощью минимума кода. Мое приложение-пример состоит примерно из 110 строк кода на JavaScript. Эта версия короче, чем версия на основе Knockout, и вдобавок я безо всяких усилий получил поддержку истории браузера. С другой стороны, Ember также является весьма «своенравной» инфраструктурой. Если вы не пишете код в стиле Ember, то скорее всего попадете в неприятности. Так что при выборе инфраструктуры следует принимать во внимание набор функциональности, стиль кодирования и то, насколько общая архитектура инфраструктуры подходит под ваши требования.

Где узнать больше

В этой статье я показал, как JavaScript-инфраструктуры упрощают создание SPA. Попутно я рассказал о некоторых общих средствах этих библиотек, в том числе о связывании с данными, маршрутизации и шаблонах MVC и MVVM. Узнать больше о создании SPA с помощью ASP.NET можно по ссылке asp.net/single-page-application.

Майк Уоссон (Mike Wasson) — программист и технический писатель в Microsoft. Многие годы занимался документированием мультимедийной части Win32 API. В настоящее время пишет о ASP.NET с основным акцентом на Web API. С ним можно связаться по адресу mwasson@microsoft.com.

Выражаю благодарность за рецензирование статьи эксперту Microsoft Хиньяну Чу (Xinyang Qiu).

Курс 20486D: Разработка Web приложений с использованием ASP.NET Core MVC

Visual Studio

SharePoint

Этот курс в нашем Центре
успешно закончили
5131 человек!

Developing ASP.NET Core MVC Web Applications

Внимание! Данный курс участвует
в программе Microsoft Plus.

А это значит, что уже с первого занятия вместе с учебными материалами вам будет предоставлен полугодовой доступ к практическим тестам Measure Up в подарок. В свободное от занятий время Вы сможете проверить и закрепить полученные знания.

Увлекательно и эффективно — запоминаемость увеличивается
с 20 вплоть до 90%.

Курс читается по последней версии!

На занятиях курса Вы научитесь создавать веб-приложения с использованием ASP.NET CORE MVC из .NET Framework. Вы получите знания и навыки, которые позволят Вам заметно повысить производительность и масштабируемость разработанных Вами веб-приложений. В ходе занятий Вы сравните технологии ASP.NET CORE MVC и ASP.NET Web Forms и получите рекомендации по выбору той или иной технологии.

Курс рассчитан на профессиональных веб-разработчиков, имеющих опыт создания приложений с использованием Visual Studio.

Для обучения на данном курсе Вам необходим действующий доступ к аккаунту Microsoft Azure. Примите во внимание, что получение нового доступа может занимать до 48 часов. Если у Вас нет доступа – просьба сообщить об этом Вашему менеджеру при записи на обучение. В этом случае мы предоставим Вам trial-версию: 30-дневный Windows Azure Pass.

Вам необходима усиленная практика? Готовитесь к сдаче сертификационных экзаменов Microsoft? Приобретите доступ к Labs Online – виртуальным лабораторным работам по авторизованным курсам Microsoft – в течение всего курса и двух недель по окончании обучения! Услуга уникальна и доступна только в Центре «Специалист»

Скидка до 60% всем слушателями и выпускникам Центра «Специалист» на курсы английского языка.

Скидка не суммируется с программой «Резерв» и другими скидками Центра «Специалист».

По окончании курса Вы будете уметь:

  • Описывать основные технологии Microsoft в области веб-разработки и выбирать наиболее подходящие для решения ваших задач.
  • Проектировать веб-приложения, удовлетворяющие различным требованиям.
  • Создавать модели шаблона CORE MVC и реализовывать бизнес-логику в рамках этих моделей.
  • Создавать контроллеры CORE MVC приложения, взаимодействующие с пользователями, моделями и представлениями данных.
  • Создавать представления CORE MVC приложения, предназначенные для отображения и редактирования данных, а также для взаимодействия с моделями и контроллерами.
  • Создавать unit-тесты и использовать средства отладки Visual Studio при разработке веб приложений.
  • Создавать веб-приложения, использующие удобочитаемые для человека URL.
  • Использовать единый интерфейс и стиль в Вашем MVC приложении.
  • Ускорить взаимодействие с пользователем за счет кэширования и частичного обновления страниц.
  • Создавать клиентский код на JavaScript, использующий библиотеку jQuery.
  • Создавать защищенные CORE MVC приложения.
  • Использовать веб-сервисы Microsoft Azure из Вашего CORE MVC приложения.
  • Разворачивать CORE MVC приложения.

Специалисты, обладающие этими знаниями и навыками, в настоящее время крайне востребованы. Большинство выпускников наших курсов делают успешную карьеру и пользуются уважением работодателей.

Развертывание и хостинг веб-приложений ASP.NET Core 2.0

Enviroment

Моя локальная среда для разработчиков — это ПК с Windows 10 с использованием Visual Studio 2020.

ПРИМЕЧАНИЕ. В настоящий момент я могу получить доступ только к своему веб-серверу через cpanel. Однако, если хостинг-провайдер не сможет обеспечить адекватную поддержку приложения ASP.NET Core 2.0, я буду смотреть на изменение на выделенный сервер, где у меня есть полный доступ к серверу и IIS.

Мои требования/проект

Я разрабатываю веб-приложение ASP.NET, ориентированное на платформу .NET Core 2.0, и приложение отлично работает с localhost и IIS express.

Теперь, когда приложение завершено, мне нужно развернуть и разместить хост, что кажется сложной задачей, которая добавит годы к моему возрасту в течение нескольких дней и недель.

Я читал о пользователях, которые прошли через множество статей, блогов, документов MS, stackoverflow и т.д. (часто безуспешно) для развертывания как в Intranet, так и в Интернете. Теперь я чувствую, что публикация и развертывание ядра .net кажутся полной массой путаницы.

Мой текущий сайт был разработан сторонней стороной — сайт WordPress с использованием PHP. Я хочу заменить этот сайт своим веб-приложением ASP.NET Core2.0.

Корнем моего текущего сайта является «httpdocs», где у меня есть некоторые вложенные папки с файлами изображений, которые мне нужны для ссылок из других приложений. Я не уверен, что они могут оставаться такими, как есть, или мне нужно перенести их в новую папку, в которой находится веб-приложение ASP.NET. У меня нет доступа к серверу напрямую, я могу получить доступ только через cpanel.

Для приложения требуется https, а ниже я включил файлы Startup.cs и Program.cs.

Я изложил шаги и соображения, которые, как мне кажется, участвуют в развертывании и хостинге. Может ли кто-нибудь, у кого был предыдущий опыт работы с этим, помогите с моими вопросами или сообщите мне о чем-нибудь, что я пропустил, или о других вещах, которые я должен рассмотреть?

Startup.cs

Program.cs

UseIISIntegration() сообщает ASP.NET, что IIS будет работать как обратный прокси-сервер перед Kestrel. Это также указывает некоторые параметры, по которым должен прослушиваться порт Kestrel, пересылать заголовки и другие данные. UseKestrel() регистрирует интерфейс IServer для Kestrel как сервера, который будет использоваться для размещения приложения.

Я не сомневаюсь, что мне нужно что-то изменить здесь или просто использовать опции deafult.

Я читал: Microsoft рекомендует использовать IIS с любым открытым сайтом для основного хоста ASP.NET. IIS предоставляет дополнительные уровни конфигурируемости, управления, безопасности, ведения журналов и многое другое. Одним из больших преимуществ использования IIS является управление процессом. IIS автоматически запустит ваше приложение и, возможно, перезапустит его, если произойдет сбой. Если вы использовали приложение ASP.NET Core в качестве приложения Windows или консольного приложения, у вас не было бы такой сети безопасности, чтобы начать и контролировать процесс для вас.

launchSettings.json

Мне нужно внести изменения в содержимое этого файла перед публикацией? Или это автоматически изменяется при публикации приложения в папку? Например, мне нужно изменить ОКРУЖЕНИЕ на «Производство» или applicationUrl на мой домен веб-сайта?

web.config(для ядра ASP.NET)

Файл web.config должен определить, как IIS запускает мой процесс ASP.NET Core. Например, я хочу включить ведение журнала вывода, установив stdoutLogEnabled = true, и я также могу изменить местоположение вывода журнала, как это указано в stdoutLogFile.

На конфигурацию IIS влияет раздел web.config для тех функций IIS, которые применяются к конфигурации обратного прокси.

В моем проекте ASP.NET Core2 в настоящее время нет файла «web.config». Будет ли этот файл появляться при публикации моего приложения?

Опубликовать в папку

При развертывании из Visual Studio шаг публикации dotnet происходит автоматически, прежде чем файлы будут скопированы в пункт назначения развертывания.

Папка публикации содержит файлы .exe и .dll для приложения, его зависимостей и, возможно, время выполнения .NET. В дополнение к файлам .exe и .dll папка публикации для основного приложения ASP.NET обычно содержит файлы конфигурации, статические активы и представления MVC.

Приложение .NET Core может быть опубликовано как автономное или зависимое от платформы приложение. Если приложение является самодостаточным, файлы .dll, которые содержат среду выполнения .NET, включены в папку публикации. Если приложение зависящее от структуры, файлы среды выполнения .NET не включены, потому что приложение имеет ссылку на версию .NET, установленную на сервере.

Как я устанавливаю для IIS на сервере Windows, я считаю, что я должен использовать модель развертывания по умолчанию, которая зависит от структуры.

Диспетчер процессов

Приложение ASP.NET Core — консольное приложение, которое должно запускаться, когда сервер загружается и перезапускается, если он сбой. Для автоматизации запуска и перезапуска требуется диспетчер процессов. Я знаю, что могу использовать Apache для Linux, но в этом случае мне нужно использовать IIS, поскольку мой текущий сайт — это сервер Windows.

Настройка обратного прокси

Сценарий, требующий обратного прокси-сервера, — это когда у вас несколько приложений, которые используют один и тот же IP-порт и порт на одном сервере. Это не работает с Kestrel напрямую, потому что Kestrel не поддерживает совместное использование одного и того же IP и порта между несколькими процессами. Когда вы настраиваете Kestrel для прослушивания на порту, он обрабатывает весь трафик для этого порта независимо от заголовка хоста. Обратный прокси-сервер, который может совместно использовать порты, должен затем пересылать Kestrel на уникальный IP-адрес и порт.

Согласно MS, существуют другие причины использования обратного прокси-сервера. Например, это упрощает балансировку нагрузки и настройку SSL. Для вашего обратного прокси-сервера требуется сертификат SSL, и этот сервер может связываться с серверами приложений во внутренней сети с помощью простого HTTP.

Установить .NET Core Windows Server Hosting Bundle

Я прочитал, что перед развертыванием моего приложения мне нужно установить пакет хостинга .NET Core для IIS на хостинге. Это установит среду выполнения .NET Core, библиотеки и модуль ядра ASP.NET для IIS. После его установки вам может потребоваться «net stop was/y» и «net start w3svc», чтобы все изменения были отобраны для IIS.

Я могу получить доступ только к своему веб-серверу через cpanel, поэтому я думаю, что мой хостинг-провайдер должен будет это сделать.

Сертификат SSL

Поскольку я использую https, я считаю, что мне нужно будет приобрести сертификат SSL и установить его в IIS.

Настройка IIS — создание приложения в IIS

Я могу получить доступ только к своему веб-серверу через cpanel, поэтому я думаю, что это также потребуется сделать моим хостинг-провайдером.

Пишем свой первый RESTful веб-сервис на ASP.NET

Что такое RESTful веб-сервис?

REST используется для создания легковесных, поддерживаемых и масштабируемых веб-сервисов. Сервис, построенный на REST архитектуре, называется RESTful-сервисом. REST использует HTTP — базовый сетевой протокол.

Ключевые составляющие RESTful

Веб-сервисы прошли долгий путь с момента их появления. В 2002 году W3C выпустил определения WSDL и SOAP веб-сервисов. Это сформировало стандарт по созданию веб-сервисов.

В 2004 году W3C выпустил определение ещё одного стандарта под названием RESTful. В последние годы этот стандарт стал довольно популярным. На данный момент он используется многими известными сайтами по всему миру, в число которых входят Facebook и Twitter.

20 ноября в 18:30, Москва, беcплатно

REST — это способ получить доступ к ресурсам, которые находятся в определённой среде. Например, у вас может быть сервер с важными документами или фотографиями. Всё это — ресурсы. Если клиенту, скажем, веб-браузеру, нужны какие-то из этих ресурсов, ему необходимо отправить запрос на сервер для получения доступа к ним. REST определяет, как может осуществляться доступ к этим ресурсам.

Ключевые составляющие реализации RESTful:

  1. Ресурсы. Допустим, у нас есть сервер с записями о сотрудниках, а адрес веб-приложения — http://server.com. Чтобы получить доступ к записи сотрудника, мы можем выполнить команду http://server.com/employee/1, которая говорит серверу предоставить запись сотрудника под номером 1.
  2. Методы запросов. Они говорят, что вы хотите сделать с ресурсом. Браузер использует метод GET, чтобы проинформировать удалённую сторону о том, что он хочет получить данные. Кроме GET есть много других методов вроде POST, PUT и DELETE. В примере с http://server.com/employee/1 выше браузер на самом деле использует метод GET, поскольку он хочет получить данные о сотруднике.
  3. Заголовки запроса. Это дополнительные инструкции, посылаемые вместе с запросом. Они могут определять тип необходимого ресурса или подробности авторизации.
  4. Тело запроса. Это данные, отправляемые вместе с запросом. Данные обычно отправляются, когда выполняется POST-запрос к REST веб-сервису. Зачастую в POST-запросе клиент говорит серверу, что он хочет добавить на него ресурс. Следовательно, тело запроса содержит подробную информацию о ресурсе, который необходимо добавить на сервер.
  5. Тело ответа. Это основная часть ответа. В нашем примере на запрос http://server.com/employee/1 сервер мог бы прислать XML-документ с данными о сотруднике в теле ответа.
  6. Коды ответа. Эти коды возвращаются сервером вместе с ответом. Например, код 200 обычно означает, что при отправке ответа не произошло никакой ошибки.

Методы RESTful

Представим, что у нас есть RESTful веб-сервис по адресу http://server.com/employee/. Когда клиент делает запрос к нему, он может указать любой из обычных HTTP-методов вроде GET, POST, DELETE и PUT. Ниже указано, что могло бы произойти при использовании соответствующего метода:

  • POST — с его помощью можно создать новую запись сотрудника;
  • GET — с его помощью можно запросить список сотрудников;
  • PUT — с его помощью можно обновить данные сотрудников;
  • DELETE — с его помощью можно удалять записи сотрудников.

Посмотрим на это с точки зрения одной записи. Допустим у нас есть запись сотрудника под номером 1. Вот какое значение могли бы иметь следующие действия:

  • POST — этот метод нельзя применить, так как сотрудник с номером 1 уже существует;
  • GET — этот метод можно использовать для получения данных о сотруднике под номером 1;
  • PUT — этот метод можно использовать для обновления данных сотрудника под номером 1;
  • DELETE — этот метод можно использовать для удаления записи сотрудника под номером 1.

Почему RESTful

В основном популярность RESTful обусловлена следующими причинами:

1. Разнородные языки и среды — это одна из основных причин:

  • У веб-приложений, написанных на разных языках, есть возможность взаимодействовать друг с другом;
  • Благодаря RESTful эти приложения могут находиться в разных средах, будь то Windows или Linux.

Представим, что для работы с такими сайтами как Facebook, Twitter, Google и т. д. клиентскому приложению нужно знать, на каких языках и на какой платформе они написаны. Основываясь на этих знаниях, мы могли бы написать код для взаимодействия с ними, однако это превратилось бы в сущий ад.

Facebook, Twitter и Google дают доступ к их функциональности посредством RESTful веб-сервисов. Это даёт возможность любому клиентскому приложению взаимодействовать с этими сервисами с помощью REST.

2. Технологический бум – сегодня всё должно работать на разнообразных устройствах, будь то смартфон, ноутбук или кофеварка. Представляете, каких бы усилий стоило наладить взаимодействие этих устройств с помощью обычных веб-приложений? RESTful API делают эту задачу гораздо проще, поскольку, как было упомянуто выше, вам не нужно знать, что у устройства «под капотом».

3. Появление облачных сервисов — всё переезжает в облако. Приложения медленно перемещаются в облачные системы вроде Azure или Amazon, которые предоставляют большое количество API на основе RESTful архитектуры. Следовательно, приложения должны разрабатываться таким образом, чтобы они были совместимы с облаком. Так как все облачные архитектуры работают на основе REST, логично разрабатывать веб-сервисы тоже на REST-архитектуре, чтобы извлечь максимум пользы из облачных сервисов.

RESTful архитектура

Приложение или архитектура считается RESTful, если ей присущи следующие характеристики:

  1. Состояние и функциональность представлены в виде ресурсов — это значит, что каждый ресурс должен быть доступен через обычные HTTP-запросы GET, POST, PUT или DELETE. Так, если кто-то хочет получить файл на сервере, у них должна быть возможность отправить GET-запрос и получить файл. Если он хочет загрузить файл на сервер, то у него должна быть возможность использовать POST или PUT-запрос. Наконец, если он хочет удалить файл, должна быть возможность отправить запрос DELETE.
  2. Архитектура клиент-сервер, отсутствие состояния (stateless) и поддержка кеширования:
    • Клиент-сервер — обычная архитектура, где сервером может быть веб-сервер, на котором, на котором размещено приложение, а клиентом — обычный веб-браузер;
    • Архитектура без сохранения состояния означает, что состояние приложения не сохраняется в REST. Например, если вы удалили ресурс с сервера командой DELETE, то даже при получении положительного кода ответа нет гарантий, что он действительно был удалён. Чтобы убедиться, что ресурс удалён, необходимо отправить GET-запрос. С его помощью можно запросить ресурсы, чтобы посмотреть, присутствует ли там удалённый.

Принципы и ограничения RESTful

Архитектура REST основывается на нескольких характеристиках, которые описаны ниже. Любой RESTful веб-сервис должен им соответствовать, чтобы называться таковым. Эти характеристики также известны как принципы проектирования, которым нужно следовать при работе с RESTful-сервисами.

RESTful клиент-сервер

Это самое важное требование REST-архитектуры. Оно означает, что на сервере располагается RESTful веб-сервис, который предоставляет необходимую функциональность клиенту. При отправке клиентом запроса к веб-сервису сервер должен либо отклонить его, либо принять и предоставить соответствующий ответ.

Отсутствие состояния

Эта концепция означает, что задачей именно клиента является убедиться, что серверу передаются все необходимые данные. Это нужно для того, чтобы сервер мог составить ответ должным образом. Это простая независимая последовательность вопросов-ответов. Клиент задаёт вопрос, сервер отвечает соответствующим образом. Затем клиент задаёт другой вопрос, однако сервер не помнит, что было до этого, поэтому отвечает на него независимо.

Концепция кеша помогает нивелировать проблему отсутствия состояния. Так как каждый запрос клиента независим по своей природе, порой клиент может повторно отправить какой-нибудь запрос. Запрос придёт на сервер, и сервер отправит ответ. Это увеличивает сетевой трафик. Кеш позволяет клиенту хранить прежде отправленные запросы и ответы. Поэтому при повторной отправке запроса он не будет отправлен серверу; вместо этого необходимые данные будут взяты из кеша.

Многослойная система

Суть этой концепции заключается в том, что любой дополнительный слой вроде промежуточного (слой, в котором создаётся бизнес-логика; это может быть дополнительный сервис, с которым клиент взаимодействует до сервера) можно поместить между клиентом и сервером, на котором располагается RESTful веб-сервис. Однако этот слой должен быть внедрён прозрачно, чтобы он не нарушил взаимодействия клиента и сервера.

Единообразие интерфейса

Это фундаментальное требование дизайна RESTful-сервисов. RESTful работает на уровне HTTP и использует нижеприведённые методы для работы с ресурсами на сервере:

  • POST — для создания ресурса;
  • GET — для его получения;
  • PUT — для его обновления;
  • DELETE — для его удаления.

Создаём свой первый RESTful веб-сервис с ASP.NET

Веб-сервисы можно создавать на множестве языков. Многие IDE можно использовать для создания REST-сервисов.

Мы напишем REST-приложение на .NET, используя Visual Studio.

Наш сервис будет работать со следующим набором данных «туториалов»:

TutorialId TutorialName
Arrays
1 Queues
2 Stacks

Мы реализуем следующие RESTful методы:

  • GET Tutorial — при его вызове клиент получает все доступные TutorialName;
  • GET Tutorial/TutorialId — при его вызове клиент получает TutorialName, соответствующее переданному TutorialId;
  • POST Tutorial/TutorialName — при его вызове клиент отправляет запрос на добавление туториала с переданным TutorialName;
  • DELETE Tutorial/TutorialId — при его вызове клиент отправляет запрос на удаление туториала с TutorialName, соответствующему переданному TutorialId.

Теперь создадим шаг за шагом наш веб-сервис.

Шаг первый

Нам нужно создать пустое ASP.NET веб-приложение. Для этого откройте Visual Studio и создайте новый проект:

После выбора этой опции должно появиться новое диалоговое окно, о котором мы поговорим в следующем шаге.

Шаг второй

В открывшемся окне перейдите по вкладкам C# → Веб. Выберите опцию «Веб-приложение ASP.NET (.NET Framework)» и введите необходимые данные проекта вроде названия и каталога:

Если далее у вас появилось следующее окно, выбирайте вариант «Пустой»:

После этого должно открыться окно, где в обозревателе решений можно увидеть наш проект:

Шаг третий

Теперь нужно создать файл нашего RESTful веб-сервиса. Для этого сначала нажмите Ctrl+Shift+A, либо кликните правой кнопкой по файлу проекта Webservice.REST и выберите опции Добавить → Создать элемент…:

В открывшемся окне найдите опцию «Служба WCF (с поддержкой технологии AJAX)» и дайте ей имя TutorialSevice.svc:

Прим. перев. Если вы не можете найти эту опцию, то попробуйте открыть Visual Studio Installer и загрузить часть среды, ответственную за работу с ASP.NET:

После выбора опции «Служба WCF (с поддержкой технологии AJAX)» Visual Studio создаст код, который будет основой для реализации веб-сервиса. WCF (Windows Communication Foundation) — библиотека, необходимая для налаживания взаимодействия между приложениями с помощью разных протоколов вроде TCP, HTTP и HTTPS. AJAX позволяет асинхронно обновлять веб-страницы, обмениваясь небольшими объёмами информации с сервером.

Шаг четвёртый

Теперь нам нужно внести изменения в конфигурационный файл Web.config. Он содержит настройки, необходимые для правильной работы приложения. Наше изменение позволит приложению отправлять и принимать данные как RESTful веб-сервис.

Откройте конфигурационный файл:

В открывшемся файле найдите строку и замените её на .

Шаг пятый

Пора приниматься за код. Откройте файл TutorialService.svc. Сначала добавим код для отображения наших данных. Создадим список со строками «Arrays», «Queues» и «Stacks». Они будут отражать имена доступных туториалов:

Шаг шестой

Теперь напишем код для нашего метода GET в том же файле. Этот метод будет запускаться при каждом вызове сервиса из браузера. Он будет использоваться для получения доступных туториалов:

Строка [WebGet(UriTemplate=»/Tutorial»)] — самая важная. Она нужна для определения того, как мы будем вызывать этот метод по URL. Если наш сервис расположен по адресу http://localhost:52645/TutorialService.svc и в его конец мы добавим «/Tutorial» и получим http://localhost:52645/TutorialService.svc/Tutorial, то будет вызван вышеприведённый код. Атрибут WebGet является параметром, который позволяет GetAllTutorials() быть RESTful-методом, который можно вызвать GET-запросом.

В самом методе GetAllTutorials() находится код, который собирает все названия туториалов и возвращает их в одной строке.

Шаг седьмой

Код, показанный ниже, нужен для того, чтобы вернуть соответствующий TutorialName при получении GET-запроса с TutorialId :

Как и в предыдущем примере, первая строка — самая важная, так как определяет то, как мы будем вызывать этот метод. Если мы сделаем запрос http://localhost:52645/TutorialService.svc/Tutorial/1, то веб-сервис должен вернуть TutorialName , соответствующий TutorialId с индексом 1.

Метод GetTutorialByID() реализует описанную логику. Обратите внимание на то, что мы приводим TutorialId к типу Integer . Это связано с тем, что всё передаваемое в адресную строку браузера является строкой. А поскольку индексом списка не может быть строка, мы добавляем код, необходимый для преобразования в число.

Шаг восьмой

Настала очередь кода для метода POST, который будет вызываться каждый раз, когда мы захотим добавить строку в наш список туториалов с помощью POST-запроса:

На первой строке находится атрибут WebInvoke , прикреплённый к нашему методу, что позволяет вызывать его с помощью POST-запроса. Для атрибутов RequestFormat и ResponseFormat мы указываем JSON, так как именно с этим форматом работает RESTful веб-сервис.

Шаг девятый

Осталось добавить метод для работы с DELETE-запросами. Он будет вызываться каждый раз, когда мы будем пытаться удалить существующее значение из списка с помощью DELETE-запроса:

Первая-вторая строки ничем особо не отличаются от предыдущих методов, они сигнализируют о том, что нижеуказанный метод будет вызываться при каждом DELETE-запросе.

В самом методе DeleteTutorial() мы приводим переданный TutorialId к типу Integer и удаляем из списка соответствующий элемент.

В итоге код должен выглядеть так (не учитывая элементов, которые были там изначально):


Запускаем наш веб-сервис

Мы создали наш веб-сервис, пора его запустить.

Сначала кликните правой кнопкой по файлу проекта Webservice.REST и выберите опцию «Назначить автозагружаемым проектом», чтобы Visual Studio запустила этот проект при запуске всего решения:

Теперь осталось запустить проект. Рядом с кнопкой запуска будет указано имя браузера, в котором будет запускаться проект. Автоматически будет предложен браузер по умолчанию, однако вам ничто не мешает выбрать другой:

После запуска должно открыться окно браузера. Перейдите по адресу http://localhost:51056/TutorialService.svc/Tutorial и в зависимости от выбранного браузера вы увидите что-то такое:

Прим. перев. В вашем случае сервис может запуститься на localhost с другим портом. Далее в статье мы будем использовать значение 51056, однако не забывайте заменять его на своё, когда будете пытаться запускать примеры.

В этом примере браузер делает GET-запрос и тем самым вызывает написанный нами метод GetAllTutorials() , который возвращает список со всеми туториалами.

Тестируем веб-сервис

Выше мы увидели, как браузер делает GET-запрос для вызова GetAllTutorials() . Давайте проверим другие сценарии.

1. GET Tutorial/TutorialId — при вызове этого RESTful API клиент должен получить TutorialName , соответствующий переданному TutorialId .

Для вызова просто добавьте строку «/1» в конце URL, чтобы получить http://localhost:51056/TutorialService.svc/Tutorial/1. После перехода по этой ссылке вы должны увидеть следующее:

В этот раз был вызван метод GetTutorialByID() , который вернул туториал с индексом 1 — «Queues».

2. POST Tutorial/TutorialName — при вызове этого API клиент отправляет запрос на добавление переданного TutorialName , который сервер должен добавить в список. В этот раз нам понадобится инструмент Fiddler, который можно бесплатно скачать с официального сайта.

Запустите Fiddler и выполните следующие действия:

  1. Переключитесь на вкладку Composer. Она используется для создания запросов, которые можно отравить любому веб-приложению;
  2. Установите тип запроса равным «POST», а в URL вставьте адрес сервиса, в нашем случае это http://localhost:51056/TutorialService.svc/Tutorial;
  3. В окне, где уже есть строка «User-Agent: Fiddler» добавьте строку «Content-Type: application/json». Наш сервис работает только с данными в формате JSON, помните?
  4. Осталось ввести данные в поле «Request Body». Наш метод для POST-запросов принимает параметр str . Передавая строку <"str": "Trees">, мы указываем, что хотим добавить в список значение «Trees».

Нажмите на кнопку «Execute». После этого нашему сервису будет отправлен запрос на добавление «Trees».

Чтобы убедиться, что всё прошло как надо, получим список всех туториалов, перейдя по ссылке http://localhost:51056/TutorialService.svc/Tutorial. Вы должны увидеть следующее:

3. DELETE Tutorial/TutorialId — при вызове этого API клиент отправит запрос на удаление из списка TutorialName , которое соответствует переданному TutorialId .

Запустите Fiddler и выполните следующие действия:

  1. Переключитесь на вкладку Composer;
  2. Установите тип запроса равным «DELETE», а в URL вставьте адрес сервиса вместе с id элемента, который хотите удалить. Если мы хотим удалить второй элемент, то адрес будет http://localhost:51056/TutorialService.svc/Tutorial/1.

Нажмите на кнопку «Execute», чтобы отправить DELETE-запрос на удаление элемента «Queues».

Если мы опять запросим список всех туториалов, мы увидим, что их стало меньше на один:

Создание первого Web API с помощью ASP.NET Core MVC и Visual Studio¶

HTTP предназначен не только для подачи веб страниц. Он также является мощной платформой для создания API, которые раскрывают сервисы и данные. HTTP прост, гибок и общедоступен. Фактически у любой платформы есть HTTP библиотека, так что HTTP сервисы могут достичь широкого круга клиентов, включая браузеры, мобильные устройства и традиционные десктоп приложения.

В этом руководстве мы создадим просто веб API для управления списком элементов “to-do”. Никакого UI здесь мы создавать не будем.

В ASP.NET Core есть встроенная поддержка MVC Web API. Унификация двух фреймворков упрощает создание приложения, которые включают в себя и UI (HTML), и API, поскольку они сейчас делят между собой и код, и поток.

Если вы портируете существующее Web API приложение в ASP.NET Core, см. Migrating from ASP.NET Web API

Обзор¶

Вот API, который мы создадим:

API Описание Тело запроса Тело ответа
GET /api/todo Получает все элементы to-do Нету Массив элементов to-do
GET /api/todo/ Получает элемент по ID Нету Элемент To-do
POST /api/todo Добавляет новый элемент Элемент To-do Элемент To-do
PUT /api/todo/ Обновляет существующий элемент Элемент To-do Нету
PATCH /api/todo/ Обновляет существующий элемент Элемент To-do Нету
DELETE /api/todo/ Удаляет элемент Нету Нету

На следующей диаграмме показан базовый дизайн приложения.

  • Клиентом является что-то, что потребляет API (браузер, мобильное приложение и тд). В этом руководстве мы не будем писать клиент. Для тестирования приложения мы будем использовать Postman.
  • Модель — это объект, который представляет в приложении данные. В данном случае единственной моделью является элемент to-do. Модели представлены как простые C# классы (POCO).
  • Контроллер — это объект, который обрабатывает HTTP запросы и создает HTTP ответы. В этом приложении будет один контроллер.
  • Для упрощения приложения мы не будем использовать БД. Элементы to-do будут храниться в памяти. Но мы включим слой доступа к данным, чтобы показать разделение между веб API и слоем данных. Если вы хотите использовать БД, просмотрите Создание первого ASP.NET Core MVC приложения с помощью Visual Studio .

Создание проекта¶

Запустите Visual Studio. Из меню File выберите New > Project.

Выберите шаблон ASP.NET Core Web Application (.NET Core). Назовите проект TodoApi , очистите Host in the cloud и нажмите OK.

В диалоговом окне New ASP.NET Core Web Application (.NET Core) — TodoApi выберите шаблон Web API. Нажмите OK.

Добавление класса модели¶

Модель — это объект, который представляет в приложении данные. В данном случае модель — это элемент to-do.

Добавьте папку “Models”. В Solution Explorer кликните правой клавишей мышки по проекту. Выберите Add > New Folder. Назовите папку Models.

Вы можете вставлять классы модели везде в проекте, но по соглашению используется папка Models.

Добавьте класс TodoItem . Кликните правой клавишей мышки по папке Models и выберите Add > > TodoItem и нажмите Add.

Замените сгенерированный код следующим:

Добавления класса репозитория¶

Репозиторий — это объект, который инкапсулирует слой данных и содержит логику для получения данных и приведения их к модели. Хотя мы не используем БД, полезно посмотреть, как внедрять репозиторий в контроллеры. Создайте код для репозитория в папке Models.

Определите интерфейс репозитория с именем ITodoRepository . Используйте шаблон (Add New Item > Class).

Этот интерфейс определяет базовые операции CRUDы.

Далее, добавьте класс TodoRepository , который реализует ITodoRepository :

Соберите приложение, чтобы проверить, что ошибок компиляции нет.

Регистрация репозитория¶

При определении интерфейса репозитория мы можем отделить класс репозитория от MVC контроллера, который его использует. Вместо создания экземпляра TodoRepository внутри контроллера мы внедрим ITodoRepository , используя встроенную поддержку ASP.NET Core для DI .

Такой подход упрощает модульное тестирование контроллеров. Юнит тесты используют “mock” или “stub” версию ITodoRepository . Тогда тесты нацелены на логику контроллера, а не на слой доступа к данным.

Чтобы внедрить репозиторий в контроллер, нам нужно зарегистрировать его с помощью DI контейнера. Откройте файл Startup.cs. Добавьте следующую директиву using:

В метод ConfigureServices добавьте выделенный код:

Добавление контроллера¶

В Solution Explorer кликните правой клавишей мышки по папке Controllers. Выберите Add > New Item. В диалоговом окне Add New Item выберите шаблон Web API Controller > TodoController .

Замените сгенерированный код следующим:

Это определит класс контроллера. В следующем разделе мы добавим методы, чтобы реализовать API.

Получение элементов to-do¶

Чтобы получить элементы to-do, добавьте следующие методы в класс TodoController .

Эти методы реализуют два метода GET:

Вот пример HTTP ответа для метода GetAll :

HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Server: Microsoft-IIS/10.0 Date: Thu, 18 Jun 2015 20:51:10 GMT Content-Length: 82

Далее в руководстве я покажу, как просмотреть HTTP ответ с помощью инструмента Postman.

Роутинг и URL пути¶

Microsoft.AspNetCore.Mvc.HttpGetAttribute` ) указывает, что это HTTP GET методы. URL путь для каждого метода построен следующим образом:

  • Возьмите строку шаблона из атрибута route контроллера, [Route(«api/[controller]»)]
  • Замените “[Controller]” именем контроллера, что является именем класса контроллера минус суффикс “Controller”. В данном примере именем класса контроллера является TodoController, а именем коревой директории — “todo”. ASP.NET MVC Core роутинг не чувствителен к регистру.
  • Если у атрибута [HttpGet] также есть строка шаблона, добавьте ее к пути. В данном примере не используется строка шаблона.

Для метода GetById “ < >todo . В рантайме, когда MVC вызывает GetById , он присваивает значение “ < >id .

В методе GetById :

«» — это переменная-заменитель для > todo . Когда вызывается GetById , он присваивает значение “ < >id .

Name = «GetTodo» создает именованный роут и позволяет вам ссылаться на этот роут в HTTP ответе. Позже я это поясню.

Возвращаемые значения¶

Метод GetAll возвращает IEnumerable . MVC автоматически сериализует объект в JSON и записывает JSON в тело ответа. Кодом ответа для этого метода является 200, если нет необработанных исключений. (Необработанные исключения переводятся в ошибки 5xx).

Метод GetById наоборот возвращает более общий тип IActionResult , который представляет широкий спектр возвращаемых типов. У GetById есть два возвращаемых типа:

  • Если ни один элемент не соответствует запрашиваемому > NotFound .
  • Иначе метод возвращает 200 с телом ответа JSON путем возвращения :dn:cls:`

Запуск приложения¶

В Visual Studio нажмите CTRL+F5, чтобы запустить приложение. Visual Studio запускает браузер и переходит по http://localhost:port/api/values , где port — это случайно выбранный номер порта. Если вы используете Chrome, Edge или Firefox, будут отображены данные. Если вы используете IE, IE предложит вам открыть или сохранить файл values.json.

Реализация других операций CRUD¶

Наконец, нам надо добавить в контроллер методы Create , Update и Delete . Я просто покажу вам код и выделю главные отличия. Соберите проект после добавления или изменения кода.

Create¶

Это метод HTTP POST, указанный атрибутом [HttpPost]. Атрибут [FromBody] говорит MVC, чтобы он получил значение элемента to-do из тела HTTP запроса.

Метод CreatedAtRoute возвращает ответ 201, являющимся стандартным ответом для метода HTTP POST, который создает новый источник на сервере. CreateAtRoute также добавляет в ответ заголовок Location. Заголовок Location определяет URI нового элемента to-do. См. 10.2.2 201 Created.

Использование Postman для отправки Create запроса¶

  • Установите HTTP метод на POST
  • Нажмите кнопку Body
  • Нажмите кнопку raw
  • Установите тип на JSON
  • В редакторе “ключ-значение” введите элемент Todo, например <"Name":" to-do item>«>
  • Нажмите Send
  • Нажмите на вкладку Headers и скопируйте заголовок Location:

Вы можете использовать заголовка Location, чтобы получить доступ к ресурсу, который создали. Снова вызовите метод GetById , созданный именованным роутом «GetTodo» :

Update¶

Update похож на Create , но он использует HTTP PUT. Ответом является 204 (No Content). В соответствии со HTTP спецификацией, запросу PUT требуется, чтобы клиент отправлял полностью обновленные данные, а не только дельты. Для частичных обновлений используется HTTP PATCH.

Обновление с Patch¶

Этот вариант похож на Update , но здесь используется HTTP PATCH. Ответом является 204 (No Content).

ASP.Net — введение, жизненный цикл и программа Hello World

ASP.Net — это платформа для веб-разработки, созданная корпорацией Microsoft . Она была выпущена в 2002 году.

Последняя версия ASP.Net — 4.6. предназначена для работы с протоколом HTTP . Это стандартный протокол, используемый во всех веб-приложениях.

ASP.Net-приложения можно создавать на различных .Net-языках . К ним относятся C # , VB.NET и J # .

Из этой статьи об ASP.Net для начинающих вы узнаете:

  • Что такое ASP.Net ?
  • О жизненном цикле ASP.Net ;
  • О жизненном цикле страницы ASP.Net ;
  • Как создать простую программу на ASP.Net .

Что такое ASP.Net?

ASP.Net — это платформа, которая используется для разработки веб-приложений. Базовая архитектура ASP.Net приведена ниже:

Архитектура .Net Framework включает в себя следующие компоненты:

  1. Язык — в .Net для разработки веб-приложений используются VB.net и C# ;
  2. Библиотека — .NET включает в себя набор библиотек стандартных классов. В частности, библиотека Web используется для разработки веб-приложений;
  3. Common Language Runtime (CLR) — общеязыковая инфраструктура или CLI . На ее основе выполняются .Net программы. CLR используется для выполнения ключевых действий. Действия включают в себя обработку исключений и освобождение ресурсов ( Garbage Collection ).

Ключевые характеристики ASP.Net , важные для начинающих:

  • Разделения дизайна и кода — позволяет легче поддерживать приложения ASP.NET . Общий тип файлов ASP.Net — aspx . Предположим, что у нас есть веб-страница с именем MyPage.aspx . К ней должен прилагаться еще один файл с именем MyPage.aspx.cs , содержащий часть кода страницы. Таким образом, Visual Studio создает отдельные файлы для каждой веб-страницы: один для дизайна, а второй для кода.
  • Управление состоянием — ASP.Net позволяет управлять состоянием. HTTP известен, как протокол, не имеющий состояний. Давайте в качестве примера рассмотрим приложение корзины интернет-магазина. Когда пользователь решил, какой товар он хочет купить, он нажимает кнопку « Добавить в корзину ».

Приложение должно запомнить информацию, касающуюся того, что пользователь решил приобрести. Это называется запоминание состояния приложения в текущий момент времени. Протокол HTTP не поддерживает состояний. Когда пользователь переходит на страницу оплаты товара, HTTP не сохраняет информацию о товарах, находящихся в корзине. Чтобы перенести их на страницу оплаты, нужно добавить код. Такая реализация может стать более сложной. Но ASP.Net позволяет управлять состояниями: запоминать товары в корзине и передавать их на страницу оплаты.

  • Кэширование — ASP.Net реализовывает концепцию кэширования. Это улучшает производительность приложения. Кэшируя те страницы, которые часто запрашиваются, их можно держать во временном хранилище. Эти страницы можно быстрее извлечь, уменьшая время отклика. Так что кэширование может значительно повысить производительность приложения.

Жизненный цикл ASP.Net

При изучении ASP.Net mvc 4 для начинающих важно знать жизненный цикл приложения. Когда запускается приложение ASP.Net , выполняется несколько этапов. Эта цепочка составляет жизненный цикл приложения:

  1. Запуск — жизненный цикл приложения ASP.NET начинается, когда пользователь выполняет запрос, направленный на веб-сервер к приложению ASP.Net . Обычно это происходит, когда пользователь переходит на главную страницу приложения в первый раз. В течение этого времени существует метод, называемый Application_Start , который выполняется на веб-сервере. В этом методе для всех глобальных переменных устанавливаются их значения по умолчанию;
  2. Создание объектов — создание на веб-сервере HttpContext , HttpRequest и HttpResponse . HttpContext — это контейнер для объектов HTTPRequest и HTTPResponse . Объект HttpRequest содержит информацию о текущем запросе, включая куки и информацию браузера. Объект HttpResponse содержит ответ, который отправляется клиенту;
  3. Создание HttpApplication — этот объект создается на веб-сервере. Он используется для обработки каждого последующего запроса, адресованного приложению. Предположим, что у нас есть два веб-приложения. Одним из них является приложение корзины, а другое — это новостной сайт. Для каждого приложения создается объект HttpApplication . Все дальнейшие запросы к каждому сайту будут обрабатываться соответствующим экземпляром HttpApplication ;
  4. Сброс — это событие вызывается до удаления экземпляра приложения. В это время можно использовать данный метод, чтобы вручную сбросить любой неуправляемый ресурс;
  5. Конец приложения — на данном этапе приложение окончательно выгружается из памяти.

Жизненный цикл страницы ASP.Net

Когда вызывается страница ASP.Net , она проходит определенный жизненный цикл. Этапы этого цикла выполняются до того момента, как ответ будет отправлен пользователю.

В рамках этой статьи ASP.Net для начинающих рассмотрим последовательность этапов обработки страницы:

  1. Запрос страницы — когда страница запрашивается, сервер проверяет, запрашивается ли она в первый раз. Если да, то страница создается, обрабатывается ответ и отправляется пользователю. Если страница запрашивается не в первый раз, проверяется кэш. Если страница существует в кэше, сохраненный ответ отправляется пользователю;
  2. Запуск страницы — на этом этапе создаются объекты Request и Response . Объект Request используется для хранения информации, которая была отправлена при запросе страницы. Объект Response используется для хранения информации, которая отправляется обратно пользователю;
  3. Инициализация страницы — на этом этапе инициализируются все элементы управления веб-страницы;
  4. Загрузка страницы — страница загружается со всеми значениями по умолчанию. Например, если текстовое поле должно иметь значение по умолчанию, оно загружается во время page load ;
  5. Валидация — в некоторых случаях для определенных форм может быть задана валидация. Например, может запрашиваться подтверждение того, что элемент списка содержит определенный набор значений. Если условие не выполняется, должна выводиться ошибка при загрузке страницы;
  6. Повторная обработка событий — возникает, если страница загружается снова. Это происходит в ответ на предыдущее событие. Если пользователь нажимает на кнопку отправки данных на странице. В этом случае та же страница отображается снова. Тогда вызывается повторный обработчик события;
  7. Отображение страницы — происходит перед тем, как ответ отправляется пользователю. Вся информация о форме сохраняется, а результат отправляется пользователю в виде полной веб-страницы;
  8. Выгрузка — после того, как страница отправляется пользователю, больше нет необходимости хранить объекты веб-формы в памяти. Таким образом, процесс выгрузки включает в себя удаление всех ненужных объектов из памяти.

Программа «Hello World» в ASP.Net

Изучение ASP.Net web forms для начинающих лучше начать с создания простого приложение « Hello, World «. Для этого необходимо выполнить следующие шаги.

Шаг 1: Создание нового проекта в Visual Studio . После запуска Visual Studio нужно выбрать пункт меню Новый> Проект :

Шаг 2: Следующим шагом является выбор типа проекта — веб-приложение ASP.NET . Здесь нужно указать название и расположение проекта.

  1. В диалоговом окне проекта выберите вариант « Веб » в левой панели. А затем « Веб-приложение ASP.Net »;
  2. Задайте имя приложения и место его хранения;
  3. Нажимаем на кнопку « OK », чтобы Visual Studio создал проект.

Шаг 3: В следующем окне нужно выбрать тип веб-приложения ASP.NET , которое должно быть создано. Мы хотим создать простое приложение веб-формы.

  • Выберите тип проекта – « Пустой »;
  • Выберите опцию « Веб-форма ». После этого будут добавлены общие папки. Они необходимы для создания базового приложения веб-формы;
  • В конце нажимаем на кнопку « OK », чтобы Visual Studio создал приложение.

Если вы выполните указанные выше шаги руководства ASP.Net для начинающих, то получите в Visual Studio результат, продемонстрированный на рисунке ниже:

В « Solution explorer » появится приложение DemoApplication . Оно содержит два файла проекта, как показано на рисунке выше. Один из ключевых файлов проекта — это Global.asax.cs . Он содержит информацию конкретного приложения. В этом файле можно инициализировать все переменные, определив для них значения по умолчанию.

Шаг 4: Теперь пришло время добавить в проект файл веб-формы. Это файл, который будет содержать весь код проекта.

  • Кликните правой кнопкой мыши по DemoApplication ;
  • Выберите из контекстного меню пункт Добавить> Веб-форма .

Шаг 5: В следующем окне задайте имя веб-формы. В нашем случае это будет Demo .

Visual Studio автоматически создаст веб-форму Demo и откроет ее.

Шаг 6: Следующим шагом является добавление кода, который позволит отобразить « Hello World «. Это можно сделать, добавив одну строку кода в файл Demo.aspx :

  • Объект Response в ASP.Net используется для передачи информации обратно пользователю. В данном случае мы используем метод Write объекта Response , чтобы написать текст « Hello World «. Маркеры используются для добавления специфического кода ASP.net .

Если вы выполните все шаги, перечисленные в этой статье об ASP.Net mvc для начинающих и запустите созданную программу в Visual Studio , то получите следующий результат:

В окне браузера отображается фраза « Hello, World «.

SPA ПРОЕКТ СОЗДАНИЕ СЕРВЕРА (ASP.NET CORE WEB API)

Мы научимся настраивать серверное приложение, заточенное полностью под новые потрясающие реали мира веб технологий. Приложение на основе веб-сервисов. Такие приложения могу работать не толко с браузерами, но и с мобильными устройствами, десктомными приложениями и т.д.

Если Вы просто хотите получить готовый каркас проекта, то просто скачайте его с гита.

Итак, сильно углубляется не будем, но, если в кранце развитие веб технологий можно разбить на два этапа синхронный принцип и асинхронный принцип работы.

синхронный — это передача небольших данных серверам и ожидание ответа от сервра, т.е. сделали запрос, который сам по себе очень легкий, страница замерла, сервер пыжится, считает, калькулирует, обращается к базе, что-то рендерит у себя, использует всякие шаблонизаторы для рендеринга, а мы, как пользователи ждем, когда ответит сервер. До этих пор мы не можем взаимодействовать со страницей, она полностью замерла или синхронизировалась с сервером в ожидании его ответа. Еще одна особенность такого подхода — это передача огромного количества данных по сети. Мы захотели просто посмотреть, например, меню сайта пиццерии, нажали на мелкую ссылку отправили опять запрос на сервер и процесс повторяется. В итоге — это тяжелые рабочие будни серверов и ленивые браузеры.

асинхронный — это передача данных серверам, но без необходимости ожидания ответа от сервера. Т.е. сделали запрос к серверу, при этом страница все еще активна мы можем нажимать другие кнопочки и ссылки, полностью взаимодействовать со страницей. Самому же серверу больше не надо рендерить километровые портянки html разметки, логика на сервере сильно упрощается за счет отсутствия рендеринга представления. И сами данные невероятно легкие, передается небольшое количество данных по сети, нет сложной работы сервера, а сами браузеры трудолюбивые и умные.

Интересен сам факт того, что данные раньше передавали через грузный формат xml огромными порциями при слабом интернете.

А сегодня передают совсем крохотный объем данных при мощных интернет соединениях.

Кто-то скажет, что пк пользователей были слабые, но не надо. Потому что уже в 2000 компы были очень мощные мы с друзьями играли во Operation Flashpoint и меня удивляла масштабность игры уже тогда, поэтому можно было сделать концепцию сильного клиента еще раньше. Но это всё лирика.

Собственно, в этом видео я расскажу, как настроить и как использовать такой север.

Давайте запустим проект. Dotnet core (https://www.microsoft.com/net/core#windowsvs2020) позволяет нам сделать это невероятно просто. Это абсолютно бесплатный и внимательно, кроссплатформенная система от Microsoft, работает на nginx, на сайте проекта можно увидить какие ОС поддерживает платформа. Наличие потрясающего языка программирования C#. Также можно писать на F# и на момент записи урока еще ожидается поддержка VB. В принципе любая технология на сегодня поддерживает простую развертку web api серверов, например, такие технологии как Node.js, PHP, Ruby, Java, Python. Я умею работать и Node.js, и php, это хорошие технологии особенно node.js, но эти языки не типизированные (хотя Node.js можно писать на TypeScript или др. препроцессорах), в общем я обожаю типизацию, поэтому в своих проектах использую в основном платформу на c#.

Итак, т.к. dotnet core кроссплатформенный вы можете использовать любой редактор кода или IDE, но я крайне рекомендую вам использовать Visual Studio 2020 Community если вы используете Windows. На мой взгляд она проще для новичка или ленивого программиста. Это тоже абсолютно бесплатная среда разработки от Microsoft, которая поддерживается большое комьюнити.

Запустите Visual Studio 2020 выберите добавить новый проект, далее выберите шаблон .NET Core и ASP.NET Core Web Application (.NET Core). Назовем наш проект “WebApiApplication”.

Из списка шаблонов выберите Web API

Проверим что в “Change Authentication” у нас ничего не указанно.

Нажмите ОК. У нас запустится проект в этом шаблоне уже всё по минимуму скомпоновано для начала работы, поэтому мы можем спокойно запустить проект.

Есть два способа запуска.

  1. Запустить проект в режиме отладки в этом режиме мы сможем просмотреть работу приложения в режиме трассировке, что крайне удобно понять работу приложения в целом. Но в этом режиме нельзя в полной мере редактировать код. Такой запуск осуществляется через нажатие клавиши
  2. Второй способ — это запустить проект в режиме IIS Express без возможности отладки, но в этом режиме мы сможем легко редактировать код. Т.е. Visual Studio сама поднимет мини сервер для нас. Такой запуск осуществляется через нажатие клавиш Ctrl + F5.
Цукерберг рекомендует:  5 ключевых навыков интернет-маркетолога
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих