Что такое код asp getnextdescription

Содержание

Типы возвращаемых значений действий контроллера в веб-API ASP.NET Core Controller action return types in ASP.NET Core web API

ASP.NET Core предоставляет следующие параметры для типов возвращаемых значений действий контроллера веб-API: ASP.NET Core offers the following options for web API controller action return types:

В этом документе объясняется, когда лучше использовать каждый тип возвращаемого значения. This document explains when it’s most appropriate to use each return type.

Определенный тип Specific type

Простейшее действие возвращает элементарный или сложный тип данных (например, string или пользовательский тип объекта). The simplest action returns a primitive or complex data type (for example, string or a custom object type). Рассмотрим следующее действие, которое возвращает коллекцию пользовательских объектов Product : Consider the following action, which returns a collection of custom Product objects:

Если не известны условия, которые необходимо соблюдать при выполнении действия, конкретного типа будет достаточно. Without known conditions to safeguard against during action execution, returning a specific type could suffice. Предыдущее действие не принимает параметры, поэтому проверка ограничений параметров не требуется. The preceding action accepts no parameters, so parameter constraints validation isn’t needed.

Если в действии необходимо учитывать известные условия, используется несколько путей возврата. When known conditions need to be accounted for in an action, multiple return paths are introduced. В этом случае рекомендуется комбинировать тип возвращаемого значения класса ActionResult с примитивным или сложным типом возвращаемого значения. In such a case, it’s common to mix an ActionResult return type with the primitive or complex return type. Для этого типа действия требуется IActionResult или ActionResult . Either IActionResult or ActionResult are necessary to accommodate this type of action.

Получение IEnumerable или IAsyncEnumerable Return IEnumerable or IAsyncEnumerable

В ASP.NET Core 2.2 и более ранних версиях получение интерфейса IAsyncEnumerable из действия приводит к тому, что сериализатор выполняет синхронную итерацию операции сбора. In ASP.NET Core 2.2 and earlier, returning IAsyncEnumerable from an action results in synchronous collection iteration by the serializer. В результате вызовы блокируются, что может стать причиной перегрузки пула потоков. The result is the blocking of calls and a potential for thread pool starvation. Представьте, что Entity Framework (EF) Core используется веб-API для доступа к данным. To illustrate, imagine that Entity Framework (EF) Core is being used for the web API’s data access needs. Во время сериализации выполняется синхронное перечисление для типа возвращаемого значения следующего действия: The following action’s return type is synchronously enumerated during serialization:

Чтобы не допустить синхронного перечисления и блокировки операций ожидания для базы данных в ASP.NET Core 2.2 и более ранних версий, вызовите ToListAsync : To avoid synchronous enumeration and blocking waits on the database in ASP.NET Core 2.2 and earlier, invoke ToListAsync :

В ASP.NET Core 3.0 и более поздних версиях получение IAsyncEnumerable из действия: In ASP.NET Core 3.0 and later, returning IAsyncEnumerable from an action:

  • больше не приводит к синхронной итерации; No longer results in synchronous iteration.
  • по эффективности не отличается от получения IEnumerable . Becomes as efficient as returning IEnumerable .

ASP.NET Core 3.0 и более поздних версий помещает результаты следующего действия в буфер перед предоставлением его сериализатору: ASP.NET Core 3.0 and later buffers the result of the following action before providing it to the serializer:

Мы рекомендуем объявлять тип возвращаемого значения для сигнатуры действия как IAsyncEnumerable для гарантированного выполнения асинхронной итерации. Consider declaring the action signature’s return type as IAsyncEnumerable to guarantee the asynchronous iteration. То есть режим итерации зависит от возвращаемого базового конкретного типа. Ultimately, the iteration mode is based on the underlying concrete type being returned. MVC автоматически буферизует все конкретные типы, которые реализуют IAsyncEnumerable . MVC automatically buffers any concrete type that implements IAsyncEnumerable .

Рассмотрим следующее действие, которое возвращает записи о продуктах со сниженной ценой как IEnumerable

: Consider the following action, which returns sale-priced product records as IEnumerable

для предшествующего действия является: The IAsyncEnumerable

equivalent of the preceding action is:

Начиная с версии ASP.NET Core 3.0, оба предшествующих действия не являются блокирующими. Both of the preceding actions are non-blocking as of ASP.NET Core 3.0.

Тип IActionResult IActionResult type

Тип возвращаемого значения IActionResult можно использовать, если в действии допускаются несколько типов возвращаемого значения ActionResult . The IActionResult return type is appropriate when multiple ActionResult return types are possible in an action. Типы ActionResult представляют различные коды состояния HTTP. The ActionResult types represent various HTTP status codes. Любой неабстрактный класс, унаследованный от квалификаторов ActionResult в виде допустимого типа возвращаемого значения. Any non-abstract class deriving from ActionResult qualifies as a valid return type. Некоторые распространенные типы возвращаемых значений в этой категории: BadRequestResult (400), NotFoundResult (404) и OkObjectResult (200). Some common return types in this category are BadRequestResult (400), NotFoundResult (404), and OkObjectResult (200). Кроме того, удобные методы в классе ControllerBase можно использовать для получения типов ActionResult из действия. Alternatively, convenience methods in the ControllerBase class can be used to return ActionResult types from an action. Например, return BadRequest(); — это сокращенная форма return new BadRequestResult(); . For example, return BadRequest(); is a shorthand form of return new BadRequestResult(); .

Так как в типе действия есть несколько типов возвращаемого значения и путей, необходимо использовать атрибут [ProducesResponseType]. Because there are multiple return types and paths in this type of action, liberal use of the [ProducesResponseType] attribute is necessary. Этот атрибут создает описательные сведения об ответе для страниц справки по веб-API, создаваемых с помощью таких инструментов, как Swagger. This attribute produces more descriptive response details for web API help pages generated by tools like Swagger. [ProducesResponseType] указывает известные типы и коды состояния HTTP, возвращаемые действием. [ProducesResponseType] indicates the known types and HTTP status codes to be returned by the action.

Синхронное действие Synchronous action

Рассмотрим следующее синхронное действие, в котором возможны два типа возвращаемых значений: Consider the following synchronous action in which there are two possible return types:

В предшествующем действии: In the preceding action:

  • возвращается код состояния 404, если продукт, представленный id , не существует в базовом хранилище данных; A 404 status code is returned when the product represented by id doesn’t exist in the underlying data store. вызывается удобный метод NotFound в качестве сокращения return new NotFoundResult(); . The NotFound convenience method is invoked as shorthand for return new NotFoundResult(); .
  • Код состояния 200 возвращается с объектом Product , если продукт не существует. A 200 status code is returned with the Product object when the product does exist. Удобный метод Ok вызывается как сокращение для return new OkObjectResult(product); . The Ok convenience method is invoked as shorthand for return new OkObjectResult(product); .

Асинхронное действие Asynchronous action

Рассмотрим следующее асинхронное действие, в котором возможны два типа возвращаемых значений: Consider the following asynchronous action in which there are two possible return types:

В предшествующем действии: In the preceding action:

  • Код состояния 400 возвращается, если описание продукта содержит строку XYZ Widget. A 400 status code is returned when the product description contains «XYZ Widget». Удобный метод BadRequest вызывается как сокращение для return new BadRequestResult(); . The BadRequest convenience method is invoked as shorthand for return new BadRequestResult(); .
  • Код состояния 201 генерируется удобным методом CreatedAtAction при создании продукта. A 201 status code is generated by the CreatedAtAction convenience method when a product is created. В качестве альтернативы вызову CreatedAtAction можно использовать return new CreatedAtActionResult(nameof(GetBy >. An alternative to calling CreatedAtAction is return new CreatedAtActionResult(nameof(GetBy >. В этом пути к коду объект Product предоставляется в тексте ответа. In this code path, the Product object is provided in the response body. Также предоставляется заголовок ответа Location с URL-адресом только что созданного продукта. A Location response header containing the newly created product’s URL is provided.

Например, следующая модель указывает на то, что запросы должны включать свойства Name и Description . For example, the following model indicates that requests must include the Name and Description properties. Если Name и Description не были указаны в запросе, происходит сбой проверки модели. Failure to provide Name and Description in the request causes model validation to fail.

Если атрибут [ApiController] применяется в ASP.NET Core 2.1 и более поздних версиях, ошибки при проверке модели приводят к коду состояния 400. If the [ApiController] attribute in ASP.NET Core 2.1 or later is applied, model validation errors result in a 400 status code. Дополнительные сведения см. в разделе Автоматические отклики HTTP 400. For more information, see Automatic HTTP 400 responses.

Тип ActionResult ActionResult type

ASP.NET Core 2.1 предоставляет тип возвращаемого значения ActionResult для действий контроллера веб-API. ASP.NET Core 2.1 introduced the ActionResult return type for web API controller actions. Он позволяет возвращать тип, производный от ActionResult или определенный тип. It enables you to return a type deriving from ActionResult or return a specific type. ActionResult имеет следующие преимущества по сравнению с типом IActionResult: ActionResult offers the following benefits over the IActionResult type:

  • Свойство Type атрибута [ProducesResponseType] можно исключить. The [ProducesResponseType] attribute’s Type property can be excluded. Например, [ProducesResponseType(200, Type = typeof(Product))] упрощается до [ProducesResponseType(200)] . For example, [ProducesResponseType(200, Type = typeof(Product))] is simplified to [ProducesResponseType(200)] . Ожидаемый тип возвращаемого значения действия вместо этого выводится из T в ActionResult . The action’s expected return type is instead inferred from the T in ActionResult .
  • Операторы неявного приведения поддерживают преобразование T и ActionResult в ActionResult . Implicit cast operators support the conversion of both T and ActionResult to ActionResult . T преобразуется в ObjectResult, то есть return new ObjectResult(T); упрощается до return T; . T converts to ObjectResult, which means return new ObjectResult(T); is simplified to return T; .

C# не поддерживает операторы неявных приведений в интерфейсах. C# doesn’t support implicit cast operators on interfaces. Следовательно, для преобразования в конкретный тип необходимо использовать ActionResult . Consequently, conversion of the interface to a concrete type is necessary to use ActionResult . Например, использование IEnumerable не работает в следующем примере: For example, use of IEnumerable in the following example doesn’t work:

Один из способов исправить приведенный выше код — возвратить _repository.GetProducts().ToList(); . One option to fix the preceding code is to return _repository.GetProducts().ToList(); .

Большинство действий имеют тип возвращаемого значения. Most actions have a specific return type. При выполнении действия могут возникнуть непредвиденные условия, и в этом случае определенный тип не возвращается. Unexpected conditions can occur during action execution, in which case the specific type isn’t returned. Например, входной параметр действия может не пройти проверку модели. For example, an action’s input parameter may fail model validation. В этом случае обычно возвращается подходящий тип ActionResult вместо конкретного типа. In such a case, it’s common to return the appropriate ActionResult type instead of the specific type.

Синхронное действие Synchronous action

Рассмотрим синхронное действие, в котором возможны два типа возвращаемых значений: Consider a synchronous action in which there are two possible return types:

В предшествующем действии: In the preceding action:

  • возвращается код состояния 404, если продукт не существует в базе данных; A 404 status code is returned when the product doesn’t exist in the database.
  • возвращается код состояния 200 с соответствующим объектом Product , если продукт существует. A 200 status code is returned with the corresponding Product object when the product does exist. До версии ASP.NET Core 2.1 строка return product; имела бы вид return Ok(product); . Before ASP.NET Core 2.1, the return product; line had to be return Ok(product); .

Асинхронное действие Asynchronous action

Рассмотрим асинхронное действие, в котором возможны два типа возвращаемых значений: Consider an asynchronous action in which there are two possible return types:

В предшествующем действии: In the preceding action:

Использование Ajax с клиентскими обратными вызовами

ASP.NET — Веб-сайты ASP.NET — Использование Ajax с клиентскими обратными вызовами

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

По этим причинам многие разработчики отказываются от написания своих клиентских сценариев вручную, даже при разработке страниц в стиле Ajax. Вместо этого они предпочитают иметь дело с высокоуровневым компонентом, который может генерировать нужный код сценария. Одним из примеров служит бесплатная библиотека jQuery, которая содержит несколько простых методов для работы с Ajax. Другим примером служит ASP.NET AJAX — более полный комплект инструментов Ajax.

Хотя и ASP.NET AJAX и jQuery являются достойным выбором, наиболее важную задачу Ajax — отправку асинхронного запроса серверу — можно решить с использованием более простого средства клиентского обратного вызова ASP.NET. предоставляют способ обновления части данных веб-страницы без необходимости в полной обратной отправке. Самое главное, что отпадает потребность в коде сценария, который использует объект XMLHttpRequest. Тем не менее, по-прежнему придется писать клиентский сценарий, который обрабатывает ответ сервера.

Создание клиентского обратного вызова

Чтобы создать клиентский обратный вызов в ASP.NET, сначала понадобится запланировать способ коммуникаций. Ниже описана общая модель:

В определенный момент происходит событие JavaScript, запуская обратный вызов сервера.

На этом этапе выполняется нормальный жизненный цикл страницы, что означает запуск всех обычных серверных событий, таких как Page.Load.

Когда этот процесс завершается (и страница должным образом инициализирована), ASP.NET выполняет серверный метод обратного вызова. Этот метод должен иметь фиксированную сигнатуру — он принимает единственный строковый параметр и возвращает единственную строку.

Как только страница получает ответ от серверного метода, она использует код JavaScript, чтобы соответствующим образом изменить веб-страницу.

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

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

На рисунке ниже показана диаграмма этого процесса:

Создание базовой страницы

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

Реализация обратного вызова

Чтобы можно было принимать обратный вызов, необходим класс, который реализует интерфейс ICallbackEventHandler. Если известно, что обратный вызов будет использоваться в нескольких страницах, имеет смысл создать выделенный класс (подобный специальному обработчику HTTP в примере применения Ajax из предыдущей статьи). Однако если требуется определить функциональность, которая предназначена для единственной страницы, ICallbackEventHandler можно реализовать непосредственно внутри веб-страницы.

Интерфейс ICallbackEventHandler определяет два метода. Метод RaiseCallbackEvent() получает данные события от браузера в виде строкового параметра. Он запускается первым. Метод GetCallbackResult() запускается следующим и возвращает результат странице.

Ключевое ограничение клиентских обратных вызовов ASP.NET состоит в том, что они вынуждают передавать данные в виде одиночных строк. При необходимости передачи более сложной информации (наподобие результирующего набора с информацией о регионе, как в рассматриваемом примере) придется разработать способ сериализации данных в строку и ее десериализации на другом конце соединения. В зависимости от сложности задачи, возможно, лучше будет воспользоваться ASP.NET AJAX.

В этом примере строковый параметр, переданный методу RaiseCallbackEvent(), содержит идентификатор RegionID для выбранного региона. Используя эту информацию, метод GetCallbackResult() подключается к базе данных и получает список всех территориальных записей в этом регионе. Эти результаты объединяются в длинную единую строку, разделенную символами |. Ниже приведен полный код:

В этом примере применять декларативную привязку данных нельзя, потому что метод обратного вызова не может непосредственно получить доступ к элементам управления на странице. В отличие от сценария обратной отправки, при вызове метода RaiseCallbackEvent() страница не находится в процессе перестроения. Вместо этого метод RaiseCallbackEvent() вызывается вне очереди, чтобы запросить некоторую дополнительную информацию. Методу обратного вызова приходится самостоятельно выполнять всю черновую работу.

Поскольку результаты должны быть возвращены в виде единственной строки (и поскольку эта строка должна быть восстановлена в коде JavaScript), код выглядит несколько громоздким. Одиночный символ вертикальной черты (|) отделяет поле TerritoryDescription от поля TerritoryID. Два последовательных символа вертикальной черты (||) обозначают начало новой строки. Например, при запросе записи с Region ID, равным 1, полученный ответ может выглядеть следующим образом:

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

Написание клиентского сценария

Клиентские сценарии подразумевают обмен данными между сервером и клиентом. Подобно тому, как сервер нуждается в методе для подготовки результатов, клиенту необходима функция, предназначенная для их приема и обработки. Функция JavaScript, которая обрабатывает ответ сервера, может иметь любое имя, но она должно принимать два параметра: result и context.

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

Однако здесь упущен один нюанс. Хотя обе стороны обмена сообщениями определены, они пока еще не связаны друг с другом. Понадобится клиентский триггер, который будет запускать обратный вызов. В данном случае необходимо реагировать на событие onchange списка регионов:

callbackRef — код JavaScript, который вызывает обратный вызов. Но как именно должна быть написана эта строка кода? К счастью, ASP.NET предоставляет удобный метод GetCallbackEventReference(), который может создать необходимую ссылку обратного вызова. Первый параметр является ссылкой на объект ICallbackEventHandler, который будет обрабатывать обратный вызов, в данном случае — содержащую страницу. Второй параметр представляет информацию, которую клиент передаст серверу. В этом примере требуется фрагмент кода JavaScript, который будет искать соответствующий элемент управления (lstRegions) и извлекать выбранное в настоящий момент значение.

Третий параметр — имя клиентской функции JavaScript, которая будет принимать результаты обратного вызова сервера. Четвертый параметр включает любую контекстную информацию, которую желательно передать клиентской функции. Это полезно при обработке нескольких обратных вызовов одной и той же функцией JavaScript, когда требуется различать, какой ответ какому вызову соответствует. Наконец, последний параметр указывает, нужно ли выполнять обратный вызов асинхронно. Этот параметр должен быть всегда установлен в true во избежание блокирования страницы в случае проблемы с сетью.

Обработчик щелчка по кнопке «OK» выглядит следующим образом:

Отключение проверки достоверности события

Ранее уже рассматривались атаки внедрением SQL и атаки внедрением в POST. Атаки внедрением POST — это атаки, в которых злоумышленник изменяет POST-запрос HTTP, отправленный серверу, включая в него значение, которое недоступно для ввода в соответствующем элементе управлении. Например, злоумышленник может изменить отправленный параметр, чтобы указать выбор элемента списка, который в действительности отсутствует в списке. Оставленный непроверенным, этот запрос может вынудить код раскрыть конфиденциальные данные.

ASP.NET защищается от атак внедрением POST с помощью проверки достоверности событий. Проверка достоверности событий обеспечивает верификацию того, что все отправленные данные имеют смысл, перед тем как ASP.NET выполнит жизненный цикл страницы. К сожалению, проверка достоверности событий часто вызывает проблемы со страницами в стиле Ajax. В рассматриваемом примере элементы динамически добавляются в список территорий. Когда пользователь выберет территорию и отправит страницу обратно, ASP.NET сгенерирует ошибку «Invalid postback or callback argument» («Недопустимый аргумент обратной отправки или обратного вызова»), поскольку выбранная территория не определена в серверном элементе управлении.

Средство проверки достоверности событий не является обязательной функцией всех элементов управления. Она реализована только для классов элементов управления, которые оснащены атрибутом SupportsEventValidation. В ASP.NET большинство элементов управления, которые полагаются на отправленные данные (ListBox, DropDownList, Checkbox, TreeView, Calendar и т.д.), используют этот атрибут. Исключение составляют элементы управления, которые не ограничивают разрешенные значения. Например, элемент управления TextBox не использует проверку достоверности событий, поскольку пользователь может вводить в нем любое значение.

Проблему проверки достоверности события можно обойти двумя способами. Самый безопасный подход — явное указание ASP.NET дополнительных значений, которые должны быть разрешены в элементе управления. (ASP.NET отслеживает все достоверные значения, используя скрытый дескриптор ввода по имени EVENTVALIDATION.) К сожалению, этот подход трудоемок и часто непрактичен.

Чтобы применить его, вызовите метод Page.ClientScript. RegisterForEventValidation() для каждого возможного значения. Это должно делаться на этапе визуализации путем переопределения метода Page.Render(), как показано ниже. Вот пример, который позволяет пользователю выбирать в элементе управления lstTerritories территорию с идентификатором TerritoryID, равным 10:

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

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

Проверку достоверности событий можно отключить также для всего веб-сайта, установив атрибут enableEventValidation элемента pages в false:

Элемент управления lstTerritories нельзя использовать для получения выбранной территории в коде. Это связано с тем, что элемент управления lstTerritories является серверной версией списка и потому не содержит динамически добавленные значения. Вместо этого выборку необходимо получать непосредственно из коллекции Request.Forms:

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

Понятно, что клиентские обратные вызовы представляют мощное средство, которое позволяет создавать более гладкие и динамичные страницы. Но помните, что клиентские обратные вызовы полагаются на функциональность XMLHttpRequest, которая ограничивает их современными браузерами. Некоторые браузеры могут поддерживать JavaScript, но не клиентские обратные вызовы. Проверка, поддерживает ли браузер обратные вызовы Ajax, осуществляется с помощью свойства Request.Browser.SupportsCallback.

Илон Маск рекомендует:  PHP парсинг HTML, с помощью simple HTML DOM

Внутреннее устройство клиентских обратных вызовов

Следует отметить, что во время выполнения обратного вызова целевая страница фактически начинает усеченный жизненный цикл. Большинство управляющих событий не будут выполняться, но обработчики событий Page.Load и Page.Init будут. Свойство Page.IsPostBack вернет true, но этот обратный вызов можно отличить от подлинной обратной отправки, проверяя свойство Page.IsCallback, которое также будет равно true. Процесс визуализации страницы полностью пропускается. Информацию о состоянии предоставления извлекается и становится доступной для метода обратного вызова, но любые вносимые изменения обратно странице не отправляются. События жизненного цикла показаны на рисунке ниже:

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

Клиентские обратные вызовы в специальных элементах управления

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

Хотя никакого ограничения на типы элементов управления, которые можно создавать с использованием динамических обратных вызовов, не существует, многие элементы управления применяют обратные вызовы просто для обновления части своего пользовательского интерфейса (например, TreeView). Проявив некоторую изобретательность, можно создать контейнерный элемент управления, который обеспечивает эту функциональность без дополнительных затрат.

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

Процесс для специального элемента управления DynamicPanel показан на рисунке ниже:

Этот элемент управления служит простейшим примером того, как технологии Ajax можно интегрировать в специальный элемент управления. Конечный результат является также относительно полезным элементом управления. Однако в реальных веб-приложениях элемент DynamicPanel, скорее всего, использоваться не будет. Дело в том, что ASP.NET AJAX включает подобную, но более мощную версию, под названием UpdatePanel, применение которой рассматривается позже.

DynamicPanel

Сначала необходимо унаследовать класс от Panel и реализовать интерфейс ICallbackEventHandler. Будучи частью ICallbackEventHandler, объект DynamicPanel должен реализовать методы RaiseCallbackEvent() и GetCallbackResult(). Этот процесс состоит из двух шагов. Первым делом, панель DynamicPanel должна инициировать событие для уведомления страницы. Страница может обработать это событие и провести соответствующие модификации. Затем элемент DynamicPanel должен сгенерировать HTML-разметку для своего содержимого. После этого он может вернуть эту информацию (наряду с клиентским идентификатором) клиентской веб-странице:

Вот код клиентского сценария, который находит панель на странице, а затем заменяет ее содержимое новым HTML-содержимым:

Вместо того чтобы жестко встраивать этот сценарий в каждую страницу, в которой используется панель, имеет смысл зарегистрировать его программно в методе DynamicPanel.OnInit():

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

К счастью, процесс можно упростить, создавая другие элементы управления, которые работают совместно с DynamicPanel. Например, можно создать элемент управления DynamicPanelRefreshLink, при щелчке на котором автоматически инициируется обновление в связанной панели.

Первым действием в реализации этого решения является возврат к DynamicPanel и реализация интерфейса ICallbackContainer. Этот интерфейс позволяет DynamicPanel предоставлять ссылку обратного вызова, вместо того, чтобы вынуждать к перемещению по странице. Чтобы реализовать ICallbackContainer, необходимо предоставить метод GetCallbackScript(), который возвращает ссылку. При этом панель может полагаться на страницу, указывая себя в качестве цели обратного вызова, и на метод RefreshPanel() как клиентский сценарий, который будет обрабатывать ответ:

Теперь все готово для реализации значительно более простой кнопки обновления. Этот элемент управления по имени DynamicPanelRefreshLink унаследован от LinkButton. Панель, с которой он должен работать, указывается в свойстве PanelID. Когда наступает время его визуализации, DynamicPanelRefreshLink с помощью метода FindControl() находит связанный с ним элемент управления DynamicPanel, а затем добавляет ссылку сценария обратного вызова в атрибут onclick:

Клиентская страница

Чтобы завершить этот пример, создайте простую текстовую страницу и добавьте в нее панель DynamicPanel и элемент DynamicPanelRefreshLink. Для создания ссылки установите свойство DynamicPanelRefreshLink.PanelID. Поместите в панель какое-то содержимое и элементы управления. И, наконец, добавьте обработчик события DynamicPanel.Refresh и используйте его для изменения содержимого либо форматирования элементов управления в панели:

Если теперь открыть страницу, легко заметить, что можно щелкнуть на элементе управления DynamicPanelRefreshLink для обновления панели, не инициируя обратной отправки страницы:

Вытащить html код с сайта, работающего на asp.net

Создам свою тему.
Имеем ресурс:
fedresurs.ru/messages

При наборе любого фильтра выдаются сообщения, по 20 на страницу. Имеем переключалку страниц.
Переключение страниц — событие, при котором не обновляется вся страница, а только блок(сайт сделан на asp.net) Т.е. если посмотреть начальный (исходный) код страницы сначала только после ввода фильтра, и потом после переключения страниц — то он не меняется.
А мне нужно отпарсить хтмл код по каждой из этих страниц. Подскажите, как вытянуть эти странички? Какой то особый ПОСТ-запрос нужен ?

29.05.2014, 11:48

Где находится html-код в ASP.NET Visual Studio
Здравствуйте, у меня такое задание оптимизировать сайт. я хотела добавить мета тегов в html.

Как средствами ASP или ASP.NET преобразовать страницу html в PDF документ?
день добрый. попытался поискать по и-нету и релибу. но ничего вразумительного не нашёл. не.

как вытащить JS-файл из библиотеки asp.net
Народ подскажите, как вытащить JS-файл из библиотеки asp.net. Т.Е. при загрузке страницы, V.Studio.

ASP.NET +HTML
Как обратиться к к элементу HTML из CS файла

HTML и ASP net
Всем привет! в общем, у есть сайт на HTML + CSS как в него внедрить C# ? или например есть 2.

29.05.2014, 14:30 2 30.05.2014, 09:09 [ТС] 3 30.05.2014, 14:34 4
30.05.2014, 14:34
30.05.2014, 14:56 [ТС] 5
30.05.2014, 15:06 6

Вам нужен:
1) http://www.telerik.com/fiddler — The free web debugging proxy for any browser, system or platform. (.NET)
2) http://portswigger.net/burp/ — По мне более привычный, и имеет свои плюсы. (.JAVA)

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

как использовать enum с DescriptionAttribute в asp.net mvc

Я новичок в asp.net MVC. Я пытаюсь использовать раскрывающийся список на странице просмотра, которая заполняется из enum. Я также хочу добавить пользовательские описания в выпадающие значения. Я искал так много примеров, но никто не опубликовал, как заполнить описание на странице просмотра. Вот мой код:

Он не заполняется полями описания, как указано в моем перечислении SearchBy. см. изображение здесь. http://postimg.org/image/phdxgocj7/ Пожалуйста, помогите мне, где я делаю ошибку. Спасибо

ОБНОВЛЕНИЕ: я получил решение для этого от Нико. И я немного исследовал это. Я обновляю этот пост с решением, потому что это может быть полезно для других, кто новичок в MVC http://weblogs.asp.net/jongalloway//looking-at-asp-net-mvc-5-1-and-web- апи-2-1-часть-1-обзор-и-перечислений

Спасибо вам всем. Наслаждайтесь кодированием ..

3 ответа

Html-помощник EnumDropDownListFor или EnumDropDownList не учитывает украшения атрибута Description элементов enum . Однако, просмотрев исходный код:

List выше вспомогательные классы enum используются для преобразования Enum в List . Из кода ниже:

Вы можете видеть, что в методе GetDisplayName он проверяет наличие DisplayAttribute в элементе enum . Если атрибут display существует, то имя устанавливается на результат метода DisplayAttribute.GetName() .

Собрав все это вместе, мы можем изменить enum для использования DisplayAttribute вместо DescriptionAttribute и установить для свойства Name значение, которое вы хотите отобразить.

Как избежать написания беспорядочного JavaScript в коде ASP.NET?

Я спрашиваю о том, что лучше всего использовать Javascript с ASP.NET.

Я не знаю, является ли это лучшей практикой, но я добавляю событие клиентской стороны javascript внутри кода. Он работает правильно, но является ли это лучшей практикой?

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

Кроме того, трудно отладить длинную строку Javascript. Как это может быть более чистым. есть ли способ?

Посмотрите пример переменной, содержащей Javascript:

Самый первый шаг — отделить JavaScript от кода и интерполяции значений. Вместо динамического построения JavaScript подход должен иметь функцию JavaScript, которая предоставляет аргументы.

После первой фазы мы получаем что-то вроде (простите частичный перевод, это причиняло мне боль) следующее. Обратите внимание на использование шаблона закрытия-построения; в реальном коде я бы добавил это как отдельный модуль.

Должно быть ясно, что код JavaScript отделен от любой интерполяции строк. Это нормальная функция, которая при вызове с определенными аргументами (определенная API) имеет определенное поведение. Хотя существуют разные подходы к «загрузке/вводу» этого JavaScript (что имеет значение при входе в систему UpdatePanels и вложенных/сложных иерархий), предположим, что он в настоящее время помещен внутри

Я нашел приятное решение для событий на стороне клиента с помощью javascript.

Итак, в основном я добавляю ClientSideEvent в файл .ascx. Например, я добавляю событие SelectedIndexChanged. Когда индекс переключателя изменяется, он вызывает функцию javascript, которая находится внутри файла .js.

Событие на стороне клиента в .ascx

После этого я добавляю javascript внутри файла с именем: ClientEvents.js

Добавить код javascript

Наконец, в codebehind я добавляю этот код в Page_Load. Таким образом, он регистрирует script и связывает пользовательский элемент управления с файлом javascript.

Свяжите файл javascript с пользовательским управлением

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

  • Не повторяйте себя (что может быть сложнее с WebForms)
  • Сделайте одно и сделайте это хорошо.

Я обнаружил, что функциональность клиентской стороны попадает в пару категорий:

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

( Примечание: В приведенном ниже коде возможно несколько ошибок, но оно должно дать вам основную идею)

Проверка формы с помощью ASP.NET WebForms

Это была область, вызывающая наибольшую боль для меня. В настоящее время я экспериментирую с использованием FluentValidation с помощью WebForms, и это действительно хорошо. Мой лучший совет относительно валидации: Не используйте валидаторы ! . Это причина, по которой люди жалуются на то, что WebForms является средой копирования и вставки. Это не должно быть так. Перед быстрым примером кода не используйте Data [Set | Table | Row] s! . Вы получаете все данные, но ни одно из них не работает. Используйте ORM, например Entity Framework или NHibernate, и все ваши страницы ASP имеют дело с классами сущностей, потому что тогда вы можете использовать что-то вроде FluentValidation:

Как только у вас есть основные сущности и валидаторы, используйте их в своем коде позади:

элементы управления UserControl/PostControl.ascx.cs

элементы управления UserControl/PostControl.ascx

Программно добавление проверки на стороне клиента

Теперь, когда у нас есть прочная основа в С#, вы можете добавлять атрибуты HTML в каждое из полей формы и использовать jQuery Validate, чтобы вызвать некоторые проверки переднего конца. Вы можете программно прокручивать правила FluentValidation:

Комплексные, многоповерочные проверки

Любая проверка, которая требует данных из более чем одного поля, не должна обрабатываться на клиенте. Сделайте это на С#. Попытка сгладить это вместе в HTML и JavaScript на странице ASP становится громоздкой и недостаточно для того, чтобы оправдать дополнительные накладные расходы и проблемы с обслуживанием.

Улучшения юзабилити

Эти фрагменты JavaScript помогают пользователям и мало выполняют бизнес-правила. В приложении, над которым я работаю, всякий раз, когда пользователь перемещает фокус в текстовое поле, каждое слово должно быть заглавным, поэтому «foo bar» становится «Foo Bar». Отправка JavaScript и событий на помощь:

Сценарии /foo.js (импортированные на каждой странице)

Чтобы отключить это поведение:

Если вы можете управлять этим в файле ASP, теперь вы полностью отделили код переднего и заднего конца!

Управление взаимодействием с пользователем

Это 800-фунтовая горилла для развития передней части. Мне нравится использовать «шаблон виджета» здесь, где вы пишете класс JavaScript, чтобы охватить поведение и использовать атрибуты HTML и имена классов в качестве перехватов для JavaScript, чтобы сделать это.

И в вашем файле ASP:

Опять же, здесь нужно сохранить JavaScript и HTML вместе, а не помещать JavaScript на С#.

Почему ASP.NET не используют в крупных компаниях?

В настоящий момент С# (asp.net) имеет целый ряд преимуществ над тем, что нам дает Java (в плане удобства и синтаксиса языка). Это правда!

Проблема заключается в том, что Java появился раньше, Java был открытым для использования на Linux. В итоге под сервера на Java написали огромный список уникальных решений, которые сейчас используют топовые команды (посмотри, что такое хадуп, например). В итоге, компании либо не видели смысла переписывать все на C#, так как уже имели билды на Java, либо не хотели тратить время на разработку того, что уже есть на Java.

Именно по этой причине Microsoft сейчас активно начинает спариваться с Linux и везде кричит, что они его любят.

ASP. Основы. Объекты и компоненты. Доступ к базам данных

Dynamic HTML представляет собой основное средство программирования клиента для Microsoft Internet Explorer 4.0 и выше, но такие программы просмотра Web, как Netscape Navigator, не поддерживают Dynamic HTML. На самом деле очень малая часть функциональности клиентской части, поддерживаемой различными программами просмотра, может рассматриваться как действительно кросс-платформенная.

Если Вы хотите разработать Интернет-узел, открытый для доступа самым различным программам просмотра, то должны перенести программирование с клиента на сервер. Такую возможность предоставляют Microsoft ASP (Active Server Pages — активные серверные страницы). По сути ASP не что иное, как сценарий на VBScript, который исполняется на сервере. Когда запрашивается страница, этот сценарий порождает HTML-текст. Это ключевая особенность ASP — клиент никогда не видит вашего кода, а только результирующий HTML, который воспринимает любая программа просмотра.

Листинг 4.1 демонстрирует простую ASP-страницу, которая создает приветствие в соответствии со временем суток. В нем текущий час определяется при помощи кода Hour(Now), где Now — функция VBScript, возвращающая текущий момент времени и дату. Если текущий час меньше 12, то приветствие задается в форме «Доброе утро!» От полудня до шести вечера сообщение имеет вид «Добрый день!», а после шести — «Добрый вечер!»

Листинг 4.1.Простой пример ASP.

Simple ASP Example

11 And Hour(Now) 17 Then

strGreeting = «Добрый вечер!»

Обратите внимание на код в листинге, окруженный специальными символами: угловыми скобками и знаками процента ( ). Такие символы означают, что это серверный код, который выполняется перед тем, как страница будет на самом деле послана программе просмотра. Если бы Вы посмотрели в Internet Explorer на результирующий HTML-текст, то увидели бы следующее (в предположении, что сейчас еще не вечер, но уже не утро):

Simple ASP Example

В этом-то и состоит суть ASP. Результат исполнения кода — обыкновенный HTML! Эту страницу можно просматривать любой программой просмотра: не только Internet Explorer, но и, например, Netscape Navigator. Иными словами, ASP предоставляет разработчику подлинную платформенную независимость

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

Скорее всего, Вы будете писать свои сценарии на VBScript, но ASP поддерживает и JavaScript. В отличие от сценариев на клиентской стороне, здесь выбор языка абсолютно не создает проблем совместимости с различными программами просмотра, поскольку весь код исполняется на сервере.

А теперь обратите внимание на ту строку, где и происходит генерация HTML-текста. Здесь для вывода приветствия используется переменная:

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

Объекты и компоненты.На самом простом уровне создание ASP-страницы — это ни что иное, как написание серверного кода для получения ожидаемого результата. Но VBScript не является полнофункциональным языком и, как только Вы приступаете к построению более сложных страниц, его выразительных средств начинает не хватать. Так, в VBScript нет встроенных функций доступа к данным; не умеет он и открывать текстовые файлы. Собственно говоря, в VBScript отсутствуют какие-либо встроенные средства доступа к каким бы то ни было внешним источникам данных. Так как же в таком случае при помощи ASP выполняются такие сложные действия, как доступ к данным? Ответ будет таким: нужно дополнить VBScript объектами и компонентами ASP.

ASP-объекты и компоненты — это не что иное, как компоненты ActiveX, подобные обычным DLL ActiveX, с которыми Вы наверняка работали в Microsoft Visual Basic. Различие между объектами и компонентами ASP состоит в том, каким образом они появляются в программе. ASP-объекты — это элементы управления ActiveX, которые в коде на VBScript доступны всегда: их не нужно создавать явно. В число объектов ASP входят Application, Session, Request, Response и Server. А вот ASP-компоненты представляют собой DLL, существующие вне структуры ASP. Эти компоненты могут быть написаны на любом языке, а некоторые по­лезные ASP-компоненты просто поставляются в комплекте с Visual InterDev. ASP-компо­ненты нужно явно создавать в коде. ASP поддерживает компоненты Database Access, File Access, Browser Capabilities, Ad Rotator и Content Linking.

Файл GLOBAL.ASA.Одна из главных трудностей разработчика для Интернета, независимо от того, какую технологию он использует, состоит в том, как сложно создать в Интернете настоящее приложение. Взаимодействие программы просмотра и Web-сервера представляет собой по сути лишенную состояния транзакцию, в ходе которой сервер посылает клиенту Web-страницу и затем забывает о его существовании. Когда клиент запрашивает другую Web-страницу, сервер ничего не помнит о предыдущем запросе. Коренная проблема для всех Web-приложений такова: как показать, что это именно приложение?

Определить приложение в среде Microsoft Windows довольно просто. Приложение запуска­ется двойным щелчком значка и завершается, когда в меню File выбран пункт Exit. В проме­жутке между двумя этими событиями данные хранятся в переменных. Но для Интернет-при­ложений это не так. Как определить, когда приложение начинается, а когда заканчивается? Можно сказать, что приложение начало работу, если пользователь зашел на узел и просмат­ривает одну из его страниц. Но что если он переходит к другому узлу, а через пять минут возвращается? Приложение все еще активно? А если пользователь отсутствовал час или два?

Проблема определения моментов запуска и завершения приложения оказывает серьезное влияние на правильное управление переменными и последовательностью выполнения. К счастью, ASP предлагает решение. Оно состоит в том, что для определения начала и завер­шения — как всего приложения, так и отдельных пользовательских сессий — используется специальный файл под названием GLOBAL.ASA. На этот файл возложено реагирование на четыре ключевых события узла: Application_OnStart (запуск приложения), Application_OnEnd (завершение приложения), Session_OnStart (начало сессии) и Session_OnEnd (завершение сессии). В листинге 4.2 приведен типичный файл GLOBAL.ASA.

Листинг 4.2.Файл GLOBAL.ASA.

Для обозначения разделов сценария GLOBAL.ASA содержит теги

Хотя GLOBAL.ASA отмечает начало и завершение приложения при помощи событий, оста­ется неясным, что же все-таки составляет собственно приложение. Одна из рабочих форму­лировок, предложенная Microsoft, определяет Интернет-приложение как виртуальный ката­лог со всеми его файлами. Если пользователь запрашивает Web-страницу из виртуального каталога под названием Bookstore, то тем самым он запускает приложение Bookstore, и в GLOBAL.ASA возбуждаются события Application_OnStart и Session_OnStart.

Согласно этому определению с приложением одновременно могут работать несколько про­грамм просмотра. Но событие Application_OnStart происходит только один раз: когда первый пользователь запрашивает Web-страницу из виртуального каталога. Когда затем страницы из этого ката­лога запрашивают другие пользователи, возбуждается только событие Session_OnStart.

В то время как приложение может относиться к нескольким программам просмотра, обра­щающимся к одному и тому же множеству Web-страниц, сессия касается какой-то одной программы просмотра, обращающейся к тем же Web-страницам. Для конкретной программы просмотра сессия длится, пока программа продолжает запрашивать страницы виртуального каталога. Если же пользователь не запрашивает Web-страницы (из данного виртуального каталога) на протяжении 20 минут (по умолчанию), сессия завершается, и возбуждается событие Session_OnEnd. Когда в данном виртуальном каталоге завершаются все сессии, возбуждается событие Application_OnEnd.

В качестве примера рассмотрим следующий сценарий. Два пользователя намереваются посе­тить на Web-узле приложение Magazine. Пользователь 1 оказывается проворнее и быст­ренько запрашивает Web-страницу DEFAULT.ASP. Тут же возбуждаются события Application_OnStart и Session_OnStart. Буквально пятью минутами позже к приложению обращается пользователь 2. Поскольку пользователь 1 как-то проявлял себя в течение последних 20 минут, приложение Magazine активно. Следовательно, возбуждается только событие Session_OnStart, сигнализируя о начале новой сессии. Кроме того, теперь для завершения приложения необходимо, чтобы завершились обе сессии.

В течение следующих 15 минут пользователь 1 не запрашивает ни­каких страниц приложе­ния Magazine. Поскольку он не проявлял активности на протяжении 20 минут, ASP приходит к выводу, что пользователь 1 закончил свою работу с приложением, и возбуждает событие Session_OnEnd. Но приложение все еще активно, поскольку в течение последних 20 минут к нему обращался пользователь 2.

Пользователь 2 работает с приложением еще час, то и дело запрашивая новые Web-страницы. Но в конце концов он отключается, а через 20 минут после того, как он покинул узел (точнее, в последний раз запросил Web-страницу приложения), возбуждается событие Session_OnEnd. Поскольку пользователь 2 был последним пользователем данного приложения, оно завершается, и возбуждается событие Application_OnEnd.

В ASP есть несколько встроенных объектов, которые доступны разработчику. Эти объекты помогают управлять многими вещами: от переменных, до передачи форм. Работать с ними легко, они вызываются из кода напрямую без какого-то особого синтаксиса.

Объект Application.Объект Application (приложение) позволяет создавать переменные приложения (application variables) — переменные, доступные всем пользователям данного приложения. Все, кто обращается к Web-страницам данного виртуального каталога, могут совместно использовать любую переменную приложения определенную для этого каталога.

В листинге 4.3 приведен пример программы, которая использует Объект Application. В нем переменная приложения служит для отслеживания времени последнего обращения к страницам приложения.

Листинг 4.3.Объект Application.

Эта страница последний раз посещалась:

Создание переменной приложения сводится к адресации объекта Application именем новой переменной, которую вы хотите создать. Например, следующий код создает новую переменную приложения с именем Company и присваивает ей значение NewTech.

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

Поскольку такие переменные доступны нескольким пользователям одновременно, вы не сможете гарантировать, что два пользователя не попытаются одновременно присвоить одной и той же переменной разные значения. Для разрешения подобных коллизий объект Application поддерживает методы Lock и UnLock. Метод Lock блокирует весь объект Application, а не только переменную, вы хотите изменить, поэтому сразу же после изменения значения переменной разблокируйте объект:

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

Объект Session.Зачастую разработчиков меньше интересуют данные, совместно используемые несколькими пользователями, зато гораздо больше — данные, связанные с конкретным пользователем. ASP поддерживает переменные для индивидуального пользователя при помощи объекта Session (сессия), который позволяет создавать переменные сессии (session variables).

Листинг 4.4 демонстрирует, как определить несколько переменных сессии в файле GLOBAL.ASA. Само по себе их определение так же просто, как и в случае переменных приложения. Все, что нужно сделать — это адресовать объект Session именем переменной, которую вы хотите создать. Основное различие между переменными этих объектов — их области видимости. Переменные сессии предназначаются для одного пользователя и живут, пока пользователь поддерживает сессию. Как только в течение 20 минут (по умолчанию) пользователь не обращается к страницам данного виртуального каталога, данные пропадают.

Листинг 4-..Создание переменных сессии.

Переменные сессии можно создавать на любой Web-странице или в файле GLOBAL.ASA, а доступны они на любой Web-странице приложения, в котором эти переменные были первоначально созданы. Получить значения переменных сессии можно, считывая их из объекта Session. Следующий фрагмент кода считывает переменные сессии, созданные в листинге 4.4, и выводит их в полях ввода:

Ранее мы определили Интернет-приложение как лишенные статуса транзакции между Web-сервером и программой просмотра. Как же тогда ASP запоминает переменные сессии для каждого пользователя приложения? Ответ будет таким: эти переменные сохраняются на сервере для каждого клиента. Программа просмотра получает от сервера уникальный идентификатор, позволяющий определить, какой набор переменных кому принадлежит. Клиент этот идентификатор (Globally Unique Identifier, GUID) сохраняет, а впоследствии посылает серверу и получает именно ему предназначенные данные. Таким образом каждый клиент может иметь свой набор данных в каждом Интернет-приложении.

Осталось сказать, что для установки или считывания впемени жизни сессии (в минутах) применяется свойство Timeout объекта Session:

Объект Request.Для передачи данные клиенту создается Web-страница, а для передачи данных в обратном направлении программа просмотра использует отправку формы (form submission). В форме содержатся текстовые поля, переключатели и т.п. Клиент размещает введенные данные в этих полях и пересылает пакет серверу. Процессом передачи формы управляют два атрибута тега

Элемент формы с типом SUBMIT — это кнопка, нажатие которой пользователем заставляет программу просмотра упаковать данные формы и отправить их. Формат пересылки данных определен строго и сервер знает, чего ожидать от клиента. Данные имеют вид пар Поле=Значение,отсылаемых серверу в формате открытого текста. Если в предыдущем примере ввести в поле Name NewTech и info@newtech.com в поле Email, то сценарию DATA.ASP будет послан следующий текст:

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

Request.Form применяется, когда данные были отправлены методом POST и именно этому сценарию. Если для отправки данных используется метод GET или сценарий вызывается с передачей параметров прямо в гиперссылке

то для разбота данных применяют свойство Request.QueryString, который работает так же, как Request.Form. Следующий фрагмент кода вернет значение поля Name из гиперссылки:

Другое свойство — Request.Cookies используются для извлечения информации из кукисов (cookies), отосланных вместе с запросом строке пользовательского агента программы просмотра. А листинг 4.5 демонстрирует применение свойства ServerVariables для определения имени компьютера, с которого клиент вызвал сценарий.

Листинг 4.5.Определение компьютера пользователя.

Вы вошли с компьютера

Переменные сервера представляют широкий круг информации о клиенте и Web-сервере. Доступ к каждой конкретной переменной сводится к чтению соответствующей переменной.

Объект Response.Этот объект управляет содержимым страницы, которую ASP возвращает программе просмотра. Фактически в комбинации знак равенства представляет собой сокращенное обозначение метода Write объекта Response. Так что следующие две строки кода эквивалентны:

Поскольку объект Response используется очень часто, такое сокращение оправдано.

Полезное свойство объекта Response — Expires. Оно задает время (в минутах) за которое страница устаревает. Если установить его в нуль, то страница будет устаревать в момент загрузки и Internet Explorer не будет ее кэшировать. Кэширование сильно влияет на разработку и может привести к тому, что приложение будет функционировать неправильно. IE кэширует страницы двумя способами: на диске и в памяти. Рассмотрим такой фрагмент кода, показывающий текущее время и дату:

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

Листинг 4.6.Страница, устаревающая уже в момент загрузки.

Forcing a Page to Expire

Еще один полезный метод объекта Response — Redirect, перенаправляющий программу просмотра на указанный URL:

Объект Server.Объект Server (сервер) представляет собой в некотором роде свалку — в том смысле, что предоставляемые им функции никак не связаны между собой, за тем исключением, что все они полезны разработчику для Интернета. Пожалуй, самая важная из всех функций объекта Server — это метод CreateObject, который создает экземпляр компонента ActiveX. Причем это может быть как встроенный компонент, входящий в комплект поставки, так и тот, который написали Вы сами на любом языке. В любом случае использование компонента ActiveX на сервере требует вызова метода CreateObject.

Аргументом метода CreateObject служит ProgID (программный идентификатор) требуемого компонента ActiveX. ProgID — это содержательное имя компонента, такое как Excel.Sheet или Word.Basic. Следующая строчка показывает, как при помощи CreateObject создать экземпляр компонента с ProgID Excel.Sheet.

Set MyObject = Server.CreateObject(«Excel.Sheet»)

Другим полезным методом объекта Server является MapPath, возвращающий фактический путь, соответствующий заданному виртуальному каталогу.

Компоненты ASP — это на самом деле просто компоненты ActiveX, наподобие тех, что Вы можете сами создать на Visual Basic или Visual C++. Но эти компоненты написаны Microsoft и поставляются вместе с Visual InterDev. Они предназначены для выполнения полезных для Web-узлов задач общего характера, включая доступ к данным. Создать их на своей странице Вы можете при помощи метода CreateObject объекта Server, а как только они созданы, смело обращайтесь к их свойствам и методам для выполнения нужных Вам задач.

Компонент ActiveX Data Objects.Самым полезным изо всех компонентов ASP следует признать компонент доступа к базам данных, называемый также ActiveX Data Objects, или сокращенно ADO. Он и содержащиеся в нем объекты применяются для чтения и записи данных в источники данных ODBC при публикации в Web информации из баз данных.

Объект Connection (подсоединение) создается методом CreateObject объекта Server, и ссылка на него помещается в переменную. Когда объект создан, его можно использовать для открытия подсоединения к любому источнику данных ODBC. Следующий фрагмент кода устанавливает подсоединение к источнику данных ODBC с названием Publications:

‘ Создаем объект Connection

Set objConnection = Server.CreateObject(«ADODB.Connection»)

‘ Открываем подсоединение к источнику данных

objConnection.Open «Publications», «sa», «» %>

Здесь objConnection — переменная для объектной ссылки на экземпляр объекта Connection. Метод Open устанавливает подсоединение, принимая в качестве аргументов имя источника данных, идентификатор пользователя и пароль.

Когда подсоединение установлено, получать информацию из источника данных можно при помощи объекта Recordset (набор записей). Этот объект умеет выполнять оператор SELECT языка SQL и возвращать набор записей, удовлетворяющих этому запросу. Как и объект Connection, Recordset создается методом CreateObject. В следующем примере программа выполняет оператор SELECT над источником данных, представленным переменной objConnection:

После того, как записи получены, для передвижения по ним можно обращаться к методам MoveFirst, MoveLast, MoveNext и MovePrevious. Затем метод Write объекта Response помещает данные на Web-страницу, которая и посылается программе просмотра. В листинге 4.7 приведен полный пример ASP-страницы, которая строит список пользователей, со­держащихся в источнике данных Data.

Листинг 4.7.Построение списка при помощи ADO.

Одна из основных задач в управляемом данными Web-приложении — управление информацией в объекте Recordset. Очень часто простой запрос возвращает гораздо больше данных, чем имеет смысл показывать. Давайте, например, посмотрим, что происходит, когда Вы обращаетесь к какой-либо поисковой системе в Интернете. Поисковая машина, получив ключевое слово, возвращает ссылки на узлы, где это ключевое слово встречается. Но зачастую обнаруживаются тысячи узлов, содержащих данное ключевое слово. Совершенно очевидно, что показать все эти узлы на одной Web-странице совершенно невозможно.

Выход состоит в разбиении на страницы (paging). Этот механизм реализован во всех поисковых системах для передачи за один раз некоей порции результатов запроса, скажем, из 10 записей. Теперь пользователь может эффективно работать с полученной информацией. Поддерживает разбиение на страницы и ADO — посредством нескольких свойств объекта Recordset: PageSize, PageCount и AbsolutePage.

При получении набора данных можно указать, что записи следует разбить на страницы. Количество строк набора данных, составляющих страницу, задается значением свойства PageSize. Затем можно определить общее количество страниц в наборе данных посредством свойства PageCount. А доступ к заданной странице обеспечивает свойство AbsolutePage.

В листинге 4.8 приведен полный пример, в котором пользователь может просматривать 10 записей за раз. Переменная сессии CurrentPage отслеживает текущую страницу. Пользователь может перейти к предыдущей порции данных или к следующему набору из 10 записей, выбрав одну из двух гипертекстовых ссылок на странице.

Листинг 4.8.Разбиение набора данных на страницы средствами ADO.

Корректный ASP.NET Core

Специально для любителей книг из серии «С++ за 24 часа» решил написать статью про ASP.NET Core.

Если вы раньше не разрабатывали под .NET или под какую-то аналогичную платформу, то смысла заходить под кат для вас нет. А вот если вам интересно узнать что такое IoC, DI, DIP, Interseptors, Middleware, Filters (то есть все то, чем отличается Core от классического .NET), то вам определенно есть смысл нажать на «Читать дальше», так как заниматься разработкой без понимания всего этого явно не корректно.

IoC, DI, DIP

Если театр начинается с вешалки, то ASP.NET Core начинается с Dependency Injection. Для того, чтобы разобраться с DI нужно понять, что такое IoC.

Говоря о IoC очень часто вспоминают голливудский принцип «Don’t call us, we’ll call you». Что означает «Не нужно звонить нам мы позвоним вам сами».

Различные источники приводят различные паттерны, к которым может быть применен IoC. И скорее всего они все правы и просто дополняют друг друга. Вот некоторые их этих паттернов: factory, service locator, template method, observer, strategy.

Давайте разберем IoC на примере простого консольного приложения.

Допустим у нас есть два простых класса, реализующих интерфейс с одним методом:

Они оба зависят от абстракции (в данном случае в виде абстракции выступает интерфейс).

И, допустим, у нас есть объект более высокого уровня, использующий эти классы:

В зависимости от параметра конструктора переменная _instance инициализируется определенным классом. Ну и далее при вызове Write будет совершен вывод на консоль или в Debug. Все вроде бы неплохо и даже, казалось бы, соответствует первой части принципа Dependency Inversion

Объекты более высокого уровня не зависят от объектов более низкого уровня. И те, и те зависят от абстракций.

В качестве абстракции в нашем случае выступает ILayer.

Но у нас должен быть еще и объект еще более высокого уровня. Тот, который использует класс Logging

Инициализируя Logging с помощью 1 мы получаем в классе Logging экземпляр класса, выводящего данные на консоль. Если мы инициализируем Logging любым другим числом, то log.Write будет выводить данные в Debug. Все, казалось бы, работает, но работает плохо. Наш объект более высокого уровня Main зависит от деталей кода объекта более низкого уровня – класса Logging. Если мы в этом классе что-то изменим, то нам необходимо будет изменять и код класса Main. Чтобы это не происходило мы сделаем инверсию контроля – Inversion of Control. Сделаем так чтобы класс Main контролировал то, что происходит в классе Logging. Класс Logging будет получать в виде параметра конструктора экземпляр класса, реализующего интерфейс интерфейс ILayer

И теперь нас класс Main будет выглядеть таким образом:

Фактически мы декорируем наш объект Logging с помощью необходимого для нас объекта.

Теперь наше приложение соответствует и второй части принципа Dependency Inversion:

Абстракции не зависят от деталей. Детали зависят от абстракций. Т.е. мы не знаем деталей того, что происходит в классе Logging, мы просто передаем туда класс, реализующий необходимую абстракцию.

Есть такой термин tight coupling – тесная связь. Чем слабее связи между компонентами в приложении, тем лучше. Хотелось бы заметить, что данный пример простого приложения немного не дотягивает до идеала. Почему? Да потому что в классе самого высокого уровня в Main у нас дважды используется создание экземпляров класса с помощью new. А есть такая мнемоническая фраза «New is a clue» — что означает чем меньше вы используется new, тем меньше тесных связей компонентов в приложении и тем лучше. В идеале мы не должны были использовать new DebugLayer, а должны были получить DebugLayer каким-нибудь другим способом. Каким? Например, из IoC контейнера или с помощью рефлексии из параметра передаваемого Main.

Теперь мы разобрались с тем, что такое Inversion of Control (IoC) и что такое принцип Dependency Inversion (DIP). Осталось разобраться с тем, что такое Dependency Injection (DI). IoC представляет собой парадигму дизайна. Dependency Injection это паттерн. Это то, что у нас теперь происходит в конструкторе класса Logging. Мы получаем экземпляр определенной зависимости (dependency). Класс Logging зависит от экземпляра класса, реализующего ILayer. И это экземпляр внедряется (injected) через конструктор.

IoC container

IoC контейнер это такой объект, который содержит в себе множество каких-то определенных зависимостей (dependency). Зависимость можно иначе назвать сервисом – как правило это класс с определенным функционалом. При необходимости из контейнера можно получить зависимость необходимого типа. Внедрение dependency в контейнер — это Inject. Извлечение – Resolve. Приведу пример самого простого самостоятельно написанного IoC контейнера:

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

Зарегистрировать зависимость (допустим, ConsoleLayer или DebugLayer которые мы использовали в прошлом примере) можно так:

А извлечь из контейнера в необходимом месте программы так:

В реальных контейнерах еще реализуется и Dispose(), позволяющий уничтожать ставшие ненужными ресурсы.

Кстати, имя IoC контейнер не совсем точно передает смысл, так как термин IoC гораздо шире по применению. Поэтому в последнее время все чаще применяется термин DI контейнер (так как все-таки применяется dependency injection).

Service lifetimes + various extension methods in Composition Root

Приложения ASP.NET Core содержат файл Startup.cs который является отправной точкой приложения, позволяющей настроить DI. Настраивается DI в методе ConfigureServices.

Этот код добавит в DI контейнер класс SomeRepository, реализующий интерфейс ISomeRepository. То, что сервис добавлен в контейнер с помощью AddScoped означает, что экземпляр класса будет создаваться при каждом запросе страницы.
Добавить сервис в контейнер можно и без указания интерфейса.

Но такой способ не рекомендуется, так как у вашего приложения теряется гибкость и появляются тесные связи. Рекомендуется всегда указывать интерфейс, так как в таком случае в любой момент времени можно заменить одну реализацию интерфейса другой. И если реализации поддерживают принцип Liskov substitution, то «легким движением руки» сменив название класса реализации вы измените и функционал всего приложения.

Есть еще 2 варианта добавить сервис – AddSingleton и AddTransient.
При использовании AddSingleton сервис создается один раз и при использовании приложения обращение идет к одному и тому же экземпляру. Использовать этот способ нужно особенно осторожно, так как возможны утечки памяти и проблемы с многопоточностью.

У AddSingleton есть небольшая особенность. Он может быть инициализирован либо при первом обращении к нему

либо сразу же при добавлении в конструктор

Вторым способом можно даже добавить параметр в конструктор.
Если хочется добавить параметр в конструктор сервиса, добавленного не только с помощью AddSingleton, но и с помощью AddTransient/AddScoped, то можно использовать лямбда выражение:

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

Если с AddSingleton и AddScoped все должно быть более-менее понятно, то AddTransient требует разъяснений. Официальная документация приводит пример, в котором определенный сервис добавлен в DI контейнер и в качестве параметра конструктора другого сервиса и отдельно самостоятельно. И вот в случае, если он добавлен отдельно с помощью AddTransient, он создает свой экземпляр 2 раза. Приведу очень-очень упрощенный пример. В реальной жизни к применению не рекомендуется, т.к. классы для упрощения не наследуют интерфейсы. Допустим у нас есть простой класс:

И есть второй класс, который содержит первый как зависимый сервис и получает эту зависимость в качестве параметра конструктора:

Теперь совершаем inject двух сервисов:

И в каком-нибудь контроллере в Action добавим получение наших зависимостей и вывод значений в окно Debug.

Так вот в результате мы получим 2 разных значения Guid. А вот если мы заменим AddTransient на AddScoped, то в результате мы получим 2 одинаковых значения.

В IoC контейнере приложений ASP.NET Core по умолчанию содержатся уже некоторые сервисы. Например, IConfiguration – сервис с помощью которого можно получить настройки приложения из файлов appsettings.json и appsettings.Development.json. IHostingEnvironment и ILoggerFactory с помощью которых можно получить текущую конфигурацию и вспомогательный класс, позволяющий проводить логирование.

Извлекают классы из контейнера с помощью следующей типичной конструкции (самый банальный пример):

В области видимости контроллера создается переменная с модификаторами доступа private readonly. Зависимость получается из контейнера в конструкторе класса и присваивается приватной переменной. Далее эту переменную можно использовать в любых методах или Action контроллера.
Иногда не хочется создавать переменную для того, чтобы использовать ее только в одном Action. Тогда можно использовать атрибут [FromServices]. Пример:

Выглядит странно, но для того, чтобы в коде не вызывать метод статического класса DateTime.Now() иногда делают так, что значение времени получается из сервиса в качестве параметра. Таким образом появляется возможность передать любое время в качестве параметра, а значит становится легче писать тесты и, как правило, становится проще вносить изменения в приложение.
Нельзя сказать, что static – это зло. Статические методы выполняются быстрее. И скорее всего static может использоваться где-то в самом IoC контейнере. Но если мы избавим наше приложение от всего статического и new, то получим большую гибкость.

Сторонние DI контейнеры

То, что мы рассматривали и то, что фактически реализует ASP.NET Core DI контейнер по умолчанию, — constructor injection. Имеется еще возможность внедрить зависимость в property с помощью так называемого property injection, но эта возможность отсутствует у встроенного в ASP.NET Core контейнера. Например, у нас может быть какой-то класс, который вы внедряем как зависимость, и у этого класса есть какое-то public property. Теперь представьте себе, что во время или после того как мы внедряем зависимость, нам нужно задать значение property. Вернемся к примеру похожему на пример, который мы недавно рассматривали.
Если у нас есть такой вот класс:

который мы можем внедрить как зависимость,

то используя стандартный контейнер задать значение для свойства мы не можем.
Если вы захотите использовать такую возможность задать значение для свойства OperationId, то вы можете использовать какой-то сторонний DI контейнер, поддерживающий property injection. К слову сказать property injection не особо рекомендуется использовать. Однако, существуют еще Method Injection и Setter Method Injection, которые вполне могут вам пригодится и которые также не поддерживаются стандартным контейнером.

У сторонних контейнеров могут быть и другие очень полезные возможности. Например, с помощью стороннего контейнера можно внедрять зависимость только в контролеры, у которых в названии присутствует определенное слово. И довольно часто используемый кейс – DI контейнеры, оптимизированные на быстродействие.
Вот список некоторых сторонних DI контейнеров, поддерживаемых ASP.NET Core: Autofac, Castle Windsor, LightInject, DryIoC, StructureMap, Unity

Хоть при использовании стандартного DI контейнера и нельзя использовать property/method injection, но зато можно внедрить зависимый сервис в качестве параметра конструктора реализовав паттерн «Фабрика» следующим образом:

В данном случае GetService вернет null если зависимый сервис не найден. Есть вариация GetRequiredService, которая выбросит исключение в случае, если зависимый сервис не найден.
Процесс получения зависимого сервиса с помощью GetService фактически применяет паттерн Service locator.

Autofac

Разберем Autofac на практическом примере. Удобно то, что сервисы из контейнера можно будет регистрировать и получать, как и дефолтным способом, так и с помощью Autofac.

Установим NuGet пакет Autofac.Extensions.DependencyInjection.
Изменим возвращаемое методом ConfigureServices значение с void на IServiceProvider. И добавим property

После этого станет возможным добавить в конец метода ConfigureServices класса Startup код вроде следующего (это лишь один из вариантов регистрации сервисов):

Здесь builder.Populate(services); добавляет в контейнер сервисы из IServiceCollection. Ну и далее уже можно регистрировать сервисы с помощью builder.RegisterType. Ах, да. Чуть не забыл. Необходимо изменить с void на IServiceProvider возвращаемое значение метода ConfigureServices.

AOP с помощью ASP.NET Core — Autofac Interseptors

Говоря про аспектно-ориентированное программирование, упоминают другой термин – cross-cutting concerns. Concern – это какая-то часть информации, которая влияет на код. В русском варианте употребляют слово ответственность. Ну а cross-cutting concerns это ответственности, которые влияют на другие ответственности. А в идеале ведь они не должны влиять друг на друга, так ведь? Когда они влияют на друг друга, то становится сложнее изменять программу. Удобнее, когда у нас все операции происходят по отдельности. Логирование, транзакции, кеширование и многое другое можно совершать с помощью AOP не изменяя код самих классов и методов.

В мире .NET часто применяется способ, когда AOP код внедряется с помощью пост-процессора в уже откомпилированный код приложения (PostSharp) Или же альтернативно можно применять интерцепторы – это такие перехватчики событий, которые можно добавлять в код приложения. Эти перехватчики, как правило, используют для своей работы уже рассмотренный нами паттерн декоратор.

Давайте создадим свой интерцептор. Самый простой и типичный пример, который проще всего воспроизвести — это логирование.
Установим дополнительно к пакету Autofac.Extensions.DependencyInjection еще и пакет Autofac.Extras.DynamicProxy
Установили? Добавим простенький класс лога, который будет вызываться при обращении к определенным сервисам.

Добавляем в нашу регистрацию Autofac регистрацию интерцептора:

И теперь при каждом обращении к классу будет вызван метод Intercept класса Logger.
Таким образом мы можем упростить себе жизнь и не писать в начале каждого метода запись в лог. Она у нас будет вестись автоматически. И при желании нам будет несложно ее изменить или отключить для всего приложения.

Также мы можем убрать .InterceptedBy(typeof(Logger)); и добавить перехват вызовов только для конкретных сервисов приложения с помощью атрибута [Intercept(typeof(Logger))] – необходимо указать его перед заголовком класса.

Middleware

В ASP.NET существует определенная цепочка вызовов кода, которая происходит при каждом request. Еще до того, как загрузился UI/MVC выполняются определенные действия.

То есть, например, если мы добавим в начало метода Configure класса Startup.cs код

то мы сможем посмотреть в консоли дебага какие файлы запрашивает наше приложение. Фактически мы получаем возможности AOP “out of box”
Немного useless, но понятный и познавательный пример использования middleware я вам сейчас покажу:

При каждом запросе начинает выполнятся цепочка вызовов. Из каждого app.Use после вызова next.invoke() совершается переход ко следующему вызову. И все завершается после того как отработает app.Run.
Можно выполнять какой-то код только при обращении к определенному route.
Сделать это можно с помощью app.Map:

Теперь если просто перейти на страницу сайта, то можно будет увидеть текст “Hello!”, а если добавить к строке адреса /Goodbye, то вам будет отображено Goodbye.

Кроме Use и Map можно использовать UseWhen или MapWhen для того, чтобы добавлять код в цепочку middleware только при каких-то определенных условиях.

До сих пор были все еще useless примеры, правда? Вот вам нормальный пример:

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

Или же вот пример локализации:

Теперь если вы к адресу страницы добавите параметр ?culture=fr то вы сможете переключить язык приложения на французский (если в ваше приложение добавлена локализация, то все сработает)

Filters

Если цепочка middleware относятся к процессам до MVC, то фильтры работают вместе с MVC.
Следующее схематическое изображение показывает, как отрабатывают фильтры

Сначала отрабатывают фильтры авторизации. Т.е. можно создать какой-то фильтр или несколько фильтров и вписать в них какой-то свой код авторизации, который будет отрабатывать при запросах.

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

Затем происходит привязка данных и выполняются Action фильтры. С их помощью можно манипулировать параметрами передаваемыми Action и возвращаемым результатом.

Exception фильтры как намекает название позволяют добавить какую-то общую обработку ошибок для приложения. Должно быть довольно удобно обрабатывать ошибки везде одинаково. Эдакий AOP-шный плюс.

Result фильтры позволяют совершить какие-то действия до выполнения Action контроллера или после. Они довольно похожи на Action фильтры, но выполняются только в случае отсутствия ошибок. Подходят для логики завязанной на View.

Все должно быть более понятно на примере. А у меня под рукой как раз есть пример упрощенного авторизационного фильтра:

Добавляете этот класс в DI контейнер (как обычно в Startup.cs)

И теперь становится возможным добавить какую-то свою авторизацию любому Action добавив следующий атрибут

Забавная штука – можно создать свое middleware и добавлять его каким-то action в качестве фильтра. Для того чтобы сделать так нужно создать класс с произвольным названием и методом Configure

Теперь этот класс можно добавлять Action-ам с помощью следующего атрибута

Введение в ASP.NET Core¶

В данной теме представлены новые концепции в ASP.NET Core, и здесь рассказывается, как разрабатывать современные веб приложения.

Что такое ASP.NET Core?¶

ASP.NET Core — это кроссплатформенный фреймворк с открытым исходным кодом для создания современных облачных веб приложений. Приложения ASP.NET Core могут быть запущены под`.NET Core `__ или под полной версией .NET Framework. Фреймворк состоит из модульных компонентов, что дает вам гибкость при создании решений. Вы можете разрабатывать и запускать ASP.NET Core приложения под Windows, Mac и Linux. ASP.NET Core имеет открытый исходный код на GitHub.

Почему ASP.NET Core?¶

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

В ASP.NET Core произошло большое число архитектурных изменений, в результате чего фреймворк стал компактным и модульным. ASP.NET Core не основывается на System.Web.dll. Он основывается на наборе пакетов NuGet. Это позволяет вам оптимизировать приложение, чтобы оно включало только те пакеты NuGet, которые вам нужны.

С ASP.NET Core вы получаете следующие фундаментальные улучшения:

  • Единую историю для сборки веб UI и веб API
  • Интеграцию современных клиентских фреймворков и рабочих процессов разработки
  • Облачную конфигурационную систему
  • Встроенное внедрение зависимостей
  • Новый легкий модульный поток HTTP запросов
  • Возможность хостинга на IIS или хостинга в самом процессе
  • Встроенный `.NET Core`_
  • Конструкцию в виде пакетов `NuGet`_
  • Новый инструментарий, который упрощает разработку
  • Возможность кроссплатформенного запуска ASP.NET приложений под Windows, Mac и Linux
  • Открытый исходный код

Анатомия приложения¶

Приложение ASP.NET Core — это просто консольное приложение, которое создает веб сервер в своем методе Main :

Microsoft.AspNetCore.Hosting.WebHostBuilder` , который следует паттерну сборки для создания хоста веб приложения. У паттерна есть методы, которые определяют веб сервер (например, UseKestrel ) и класс для запуска ( UseStartup ). В примере выше используется веб сервер Kestrel, но мы можем указать и другие серверы. В следующем разделе мы подробнее рассмотрим UseStartup . WebHostBuilder предлагает много дополнительных методов, включая UseIISIntegration для хостинга на IIS и IIS Express и UseContentRoot для указания корневой директории контента. Методы Build и Run создают IWebHost , который будет хостить приложение, и оно начнет слушать входящие HTTP запросы.

Startup¶

Метод UseStartup для WebHostBuilder указывает класс Startup для вашего приложения.

В классе Startup вы определяете поток обработки запросов, а также здесь настраиваются все сервисы, необходимые вашему приложению. Класс Startup должен быть открытым и содержать следующие методы:

  • ConfigureServices определяет, используемые вашим приложением (например, ASP.NET MVC Core, Entity Framework Core, > Configure определяет связующее ПО в потоке запросов
  • См. Запуск приложения

Сервисы¶

Сервис — это компонент для общего пользования в приложении. Сервисы доступны благодаря внедрению зависимостей. ASP.NET Core включает в себя встроенный IoC контейнер, который по умолчанию поддерживает внедрение конструктора, но вы можете легко заменить его IoC контейнером по вашему выбору. В дополнение к преимуществу слабого связывания, DI делает так, что сервисы доступны всему приложению. Например, везде доступно логирование . См. Внедрение зависимостей (Dependency Injection) .

Связующее ПО¶

В ASP.NET Core сы составляете поток запросов, используя Связующее ПО (Middleware) . Связующее ПО ASP.NET Core выполняет асинхронную логику для HttpContext , а затем либо вызывает следующее связующее ПО в цепочки, либо напрямую обрывает запрос. Обычно для связующего ПО используется “Use”, принимая зависимость для пакета NuGet и вызывая соответствующий метод расширения UseXYZ для IApplicationBuilder в методе Configure .

ASP.NET Core предлагает богатый набор связующего ПО:

С ASP.NET Core можно использовать любое связующее ПО, основанное на OWIN. См. Open Web Interface for .NET (OWIN) .

Серверы¶

Хостинговая модель ASP.NET Core напрямую не слушает запросы — она полагается на серверную реализацию HTTP, чтобы передавать запросы приложению. Переданный запрос представляется как набор интерфейсов feature, которые приложение затем компонует в HttpContext . ASP.NET Core включает в себя кроссплатформенный веб сервер, Kestrel , который обычно запускается за производственным веб сервером, таким как IIS или nginx.

Корневая директория контента¶

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

Корневая директория веб¶

Корневая директория веб (web root) — это директория для открытых статических ресурсов, таких как файлов css, js и файлов изображений. Связующее ПО статических файлов по умолчанию отрабатывает файлы только из этой директории (и поддиректорий). Путем директории является /wwwroot , но вы можете указать и другой путь с помощью WebHostBuilder .

ASP.NET Core — Написание ясного кода в ASP.NET Core с использованием встраивания зависимостей

Эта статья основана на ASP.NET Core 1.0 предварительной версии RC1. Некоторая информация может быть изменена при выпуске версии RC2.

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

ASP.NET Core 1.0

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

  • примеры жесткого связывания;
  • написание «честных» классов;
  • встраивание зависимостей в ASP.NET Core;
  • код с возможностью модульного тестирования;
  • тестирование обязанностей контроллера.

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

Жесткое связывание

Жесткое связывание (tight coupling) хорошо подходит для демонстрационного программного обеспечения. Если вы посмотрите на типичное приложение-пример, показывающее, как создавать сайты на основе ASP.NET MVC (версий 3–5), то скорее всего найдете код, подобный следующему (взят из класса DinnersController приложения-примера NerdDinner, использующего MVC 4):

Глядя на код, чтобы оценить степень его связывания, помните фразу «new является связующим».

Этот тип кода очень сложен в модульном тестировании, потому что NerdDinnerContext создается в процессе конструирования класса и требует подключения к базе данных. Неудивительно, что такие демонстрационные приложения нечасто включают какие-либо модульные тесты. Однако ваше приложение может выиграть от нескольких модульных тестов, даже если вы не занимаетесь разработкой на основе тестов, так что было бы лучше писать код, который можно было бы протестировать. Более того, этот код нарушает принцип Don’t Repeat Yourself (DRY) (принцип «не повторяйся»), поскольку каждый класс контроллера, так или иначе обращающийся к данным, содержит один и тот же код для создания EF-контекста базы данных (Entity Framework). Это делает внесение будущих изменений более дорогостоящим и подверженным ошибкам, особенно по мере развития приложения в течение длительного времени.

Глядя на код, чтобы оценить степень его связывания, помните фразу «new является связующим». То есть везде, где экземпляр класса создается с помощью ключевого слова new, ваша реализация связывается конкретно с этим кодом реализации. Dependency Inversion Principle (принцип инверсии зависимостей) (bit.ly/DI-Principle) утверждает: «Абстракции не должны зависеть от деталей — детали должны зависеть от абстракций». В этом примере детали того, как контроллер извлекает данные для передачи представлению, зависят от деталей того, как эти данные извлекаются, а именно от EF.

Вдобавок к ключевому слову new «статическое сцепление» является еще одним источником жесткого связывания, которое затрудняет тестирование и сопровождение приложений. В предыдущем примере имеется зависимость от системных часов компьютера в виде вызова DateTime.Now. Это связывание усложнило бы создание набора тестовых Dinners для использования в некоторых модульных тестах, так как их свойства EventDate пришлось бы устанавливать относительно текущему показанию часов. Это связывание можно было бы удалить из данного метода несколькими способами, самый простой из которых — переложить заботу об этом на какую-то новую абстракцию, возвращающую Dinners, чтобы это больше не было частью метода. В качестве альтернативы я мог бы сделать значение параметром, чтобы метод возвращал все Dinners после предоставленного параметра DateTime вместо использования только DateTime.Now. Наконец, можно было бы создать абстракцию для текущего времени и ссылаться на текущее время через эту абстракцию. Это может оказаться хорошим подходом, если приложение часто ссылается на DateTime.Now. (Кроме того, заметьте, что, поскольку эти обеды [dinners] предположительно происходят в разных часовых поясах, тип DateTimeOffset может быть более эффективным выбором в реальном приложении.)

Будьте честны

Другая проблема с сопровождением кода вроде этого — он нечестен со взаимодействующими с ним объектами. Вы должны избегать написания классов, экземпляры которых можно создавать в недопустимых состояниях, так как это является частым источником ошибок. Таким образом, все, что необходимо вашему классу для выполнения своих задач, должно предоставляться через его конструктор. Как утверждает Explicit Dependencies Principle (принцип явных зависимостей) (bit.ly/ED-Principle), «методы и классы должны явным образом требовать любые взаимодействующие объекты (collaborating objects), нужные им для корректной работы». Класс DinnersController имеет лишь конструктор по умолчанию, а это подразумевает, что ему не надо взаимодействовать с какими-либо объектами для корректной работы. Но что будет, если вы подвергнете его тесту? Что сделает этот код, если вы запустите его из нового консольного приложения, которое ссылается на MVC-проект?

Первое, что не удастся в этом случае, — попытка создать экземпляр EF-контекста. Код сгенерирует исключение InvalidOperationException: «No connection string named ‘NerdDinnerContext’ could be found in the application config file.» (в конфигурационном файле приложения не найдена строка подключения с именем ‘NerdDinnerContext’). Меня обманули! Для работы этому классу нужно больше, чем заявляет его конструктор! Если классу необходим какой-то способ доступа к наборам экземпляров Dinner, он должен запрашивать их через свой конструктор (или как параметры в своих методах).

Встраивание зависимостей

Встраивание зависимостей (dependency injection, DI) относится к передаче зависимостей класса или метода в виде параметров вместо «зашивания» в код этих связей через new или статические вызовы. Это набирающий популярность метод в .NET-разработке из-за обеспечения им разъединения приложений, в которых он применяется. В ранних версиях ASP.NET преимущества DI не использовались, и, хотя в ASP.NET MVC и Web API наблюдается прогресс в отношении его поддержки, ни одна из инфраструктур до сих пор не предоставляет полной поддержки, в том числе контейнер для управления зависимостями и жизненными циклами их объектов. В ASP.NET Core 1.0 DI не просто полностью поддерживается — оно повсеместно применяется в самом продукте.

В ASP.NET Core 1.0 DI не просто полностью поддерживается — оно повсеместно применяется в самом продукте.

ASP.NET Core не только поддерживает DI, но и включает DI-контейнер, также называемый контейнером Inversion of Control (IoC) или контейнером сервисов. Каждое приложение ASP.NET Core конфигурирует свои зависимости, используя этот контейнер, в методе ConfigureServices класса Startup. Данный контейнер обеспечивает необходимую базовую поддержку, но может быть заменен пользовательской реализацией, если в этом есть потребность. Более того, EF Core также имеет встроенную поддержку DI, поэтому ее конфигурирование в приложении ASP.NET Core сводится к простому вызову метода расширения. Для этой статьи я создал ответвление NerdDinner с именем GeekDinner. EF Core конфигурируется, как показано ниже:

После этого довольно легко запросить через DI экземпляр GeekDinnerDbContext от класса контроллера вроде DinnersController:

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

При конструировании DbContext в EF Core требуется несколько больше работы, чем в EF6, где просто принималась строка подключения. Дело в том, что, как и ASP.NET Core, EF Core спроектирован в расчете на большую модульность. Обычно вам не понадобится иметь дело напрямую с DbContextOptionsBuilder, так как он используется «за кулисами», когда вы конфигурируете EF через методы расширения вроде AddEntityFramework и AddSqlServer.

А можно ли это протестировать?

Тестирование приложения вручную является важным — вам нужна возможность запустить его и убедиться, что оно действительно запускается и дает ожидаемый вывод. Но поступать так всякий раз, когда вносится какое-то изменение, — пустая трата времени. Одно из значимых преимуществ свободно связанных приложений в том, что они, как правило, лучше поддаются модульному тестированию, чем жестко связанные. Еще важнее, что ASP.NET Core и EF Core гораздо проще в тестировании, чем их предшественники. Для начала я напишу простой тест, который напрямую передает в контроллер какой-то DbContext, который был сконфигурирован на использование хранилища в памяти. Я настрою GeekDinnerDbContext, используя параметр DbContextOptions, который предоставляется этим контекстом через конструктор:

Сконфигурировав это в тестовом классе, легко написать тест, показывающий, что Model в ViewResult возвращает корректные данные:

Конечно, здесь пока что мало логики для тестирования, поэтому данный тест ничего особенного и не проверяет. Критики возразили бы, что этот тест малозначим, и я согласился бы с ними. Однако это отправная точка для будущего теста, когда появится больше логики, что и будет сделано в самом ближайшем будущем. Но сначала, хоть EF Core и поддерживает модульное тестирование в памяти, я все же позабочусь о предотвращении прямого связывания с EF в своем контроллере. Нет никаких причин для связывания обязанностей UI с обязанностями инфраструктуры доступа к данным — по сути, это нарушило бы другой принцип, Separation of Concerns (принцип разделения обязанностей).

Избегайте зависимости от того, что не используется

Принцип отделения интерфейса (Interface Segregation Principle) (bit.ly/LS-Principle) утверждает, что классы должны зависеть только от той функциональности, которую они действительно используют. В случае нового DinnersController с поддержкой DI тот по-прежнему зависит от всего DbContext. Вместо склеивания реализации контроллера с EF можно было бы задействовать некую абстракцию, которая предоставляла бы необходимую функциональность.

Что на самом деле нужно этому методу действия (action method) для должного функционирования? Определенно не весь DbContext. Ему даже не требуется доступ к полному свойству Dinners контекста. Ему достаточно возможности отображать экземпляры Dinner соответствующей страницы. Простейшая .NET-абстракция, представляющая это, — IEnumerable . Поэтому я определю интерфейс, который просто возвращает IEnumerable , и это удовлетворит (большую часть) требований метода Index:

Я называю это репозитарием, поскольку он следует такому шаблону: он абстрагирует доступ к данным интерфейсом, подобным набору. Если по какой-то причине вам не нравится шаблон репозитария или имя, вы можете назвать его IGetDinners, IDinnerService или как угодно иначе (мой рецензент предложил ICanHasDinner). Независимо от того, как вы назовете этот тип, он будет служить той же цели.

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

Покончив с этим, теперь подстроим DinnersController для приема IDinnerRepository в качестве параметра конструктора вместо GeekDinnerDbContext и вызова метода List вместо прямого обращения к Dinners DbSet:

К этому моменту можно скомпилировать и запустить ваше веб-приложение, но вы столкнетесь с исключением, если перейдете к /Dinners: InvalidOperationException («Unable to resolve service for type ‘GeekDinner.Core.Interfaces.IdinnerRepository’ while attempting to activate GeekDinner.Controllers.DinnersController.») («Не удалось разрешить сервис для типа ‘GeekDinner.Core.Interfaces.IdinnerRepository’ при попытке активировать GeekDinner.Controllers.DinnersController.»). Я пока что не реализовал интерфейс, и, как только это будет сделано, мне также понадобится сконфигурировать свою реализацию для использования, когда DI будет выполнять запросы к IDinnerRepository. Реализация этого интерфейса тривиальна:

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

Чтобы сконфигурировать ASP.NET Core на встраивание правильной реализации, когда классы запрашивают IDinnerRepository, нужно добавить следующую строку кода в конец ранее показанного метода ConfigureServices:

Это выражение инструктирует DI-контейнер ASP.NET Core использовать экземпляр DinnerRepository всякий раз, когда требуется разрешить тип, зависимый от экземпляра IDinnerRepository. Scoped означает, что для каждого веб-запроса, обрабатываемого ASP.NET, будет использоваться один экземпляр. Также можно добавлять сервисы, указывая жизненные циклы Transient или Singleton. В данном случае подходит Scoped, поскольку мой DinnerRepository зависит от DbContext, который тоже использует жизненный цикл Scoped. Вот краткое описание доступных сроков жизни объектов.

  • Transient Используется новый экземпляр типа всякий раз, когда запрашивается этот тип.
  • Scoped При первом запросе в рамках данного HTTP-запроса создается новый экземпляр типа, а затем он повторно используется для всех последующих типов, разрешаемых при этом HTTP-запросе.
  • Singleton Единственный экземпляр типа создается один раз и используется всеми последующими запросами для этого типа.

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

После подключения DI приложение выполняется, как и раньше. Теперь, как показано на рис. 1, я могу тестировать его с применением новой абстракции, используя имитацию или заглушку реализации интерфейса IDinnerRepository вместо того, чтобы напрямую полагаться на EF в коде теста.

Рис. 1. Тестирование DinnersController, используя имитирующий объект

Этот тест работает независимо от того, откуда берется список экземпляров Dinner. Вы могли бы переписать код для доступа к данным, чтобы использовать другую базу данных, Azure Table Storage или XML-файлы, а контроллер все равно работал бы точно так же. Конечно, в данном случае он не делает ничего особенного, поэтому вам, возможно, интересно…

А как насчет реальной логики?

До сих пор я не реализовал никакой реальной бизнес-логики — у меня были лишь простые методы, возвращающие несложные наборы данных. Истинная ценность тестирования проявляется только при наличии логики и особых случаев, в которых вы должны убедиться, что приложение будет вести себя ожидаемым образом. Чтобы продемонстрировать это, я добавлю некоторые требования к своему сайту GeekDinner. Сайт будет предоставлять API, который позволит кому угодно отвечать на приглашение на обед. Однако для числа приглашаемых будет дополнительно задан максимум, и количество ответов на приглашение (RSVP) не должно превышать этот максимум. Пользователи, запрашивающие RSVP, когда максимум уже достигнут, должны добавляться в список ожидания. Наконец, желающие пообедать могут указывать крайний срок относительно их начального времени, по истечении которого они не станут принимать приглашения.

Я мог бы закодировать всю эту логику в метод действия (action), но считаю, что тогда на один метод было бы возложено слишком много обязанностей, особенно на UI-метод, который должен концентрироваться на задачах, связанных с UI, а не на бизнес-логике. Контроллер должен проверять, что ему передаются допустимые входные аргументы, и гарантировать возврат ответов, подходящих для клиента. Решения, выходящие за рамки этих обязанностей, и особенно бизнес-логика не относятся к компетенции контроллеров.

Лучшее место для размещения бизнес-логики — модель предметной области приложения, которая не должна зависеть от обязанностей инфраструктуры (вроде работы с базами данных или UI). Класс Dinner подходит для управления RSVP, описанными в требованиях, поскольку он будет хранить максимальное количество участников мероприятия и знать, сколько RSVP было выдано на данный момент. Однако часть логики также зависит от того, когда появляется RSVP (до или после крайнего срока), поэтому методу понадобится доступ к текущему времени.

Я мог бы просто использовать DateTime.Now, но это затруднило бы тестирование моей логики и связало бы модель предметной области с системными часами. Другой вариант — задействовать абстракцию IDateTime и встроить ее в сущность Dinner. Однако, как показывает мой опыт, лучше всего сохранять сущности вроде Dinner свободными от зависимостей, особенно если вы планируете применять какое-то O/RM-средство наподобие EF для извлечения этих сущностей с уровня хранения. В связи с этим я не хочу заполнять сущности зависимостями, да и EF определенно не смогла бы иметь с этим дело без дополнительного кода с моей стороны. Распространенный подход — изъятие логики из сущности Dinner и перенос ее в какой-либо сервис (вроде DinnerService или RsvpService), в который можно легко встраивать зависимости. Однако это обычно приводит к антишаблону анемичной модели предметной области (anemic domain model antipattern) (bit.ly/anemic-model), в которой сущности имеют очень мало логики (или вообще не имеют ее) и являются просто контейнерами состояния. Нет, в данном случае решение прямолинейное: метод может просто принимать текущее время как параметр и позволять вызывающему коду передавать его.

При таком подходе логика добавления RSVP проста (рис. 2). Для этого метода есть ряд тестов, которые демонстрируют, что он ведет себя, как ожидалось; тесты доступны в проекте-примере, сопутствующем этой статье.

Рис. 2. Бизнес-логика в модели предметной области

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

Обязанности контроллера

Часть обязанностей контроллера — проверка ModelState и обеспечение его допустимости. Для ясности я делаю это в методе действия, но в более крупном приложении я исключил бы этот повторяющийся код в каждом методе действия, используя Action Filter:

Предполагая, что ModelState допустим, метод действия должен извлечь соответствующий экземпляр Dinner по идентификатору, переданному в запросе. Если метод не может найти экземпляр Dinner с совпадающим идентификатором, он должен вернуть результат Not Found:

По завершении этих проверок метод действия может делегировать бизнес-операцию, представленную запросом, модели предметной области, вызвав метод AddRsvp класса Dinner, который вы видели ранее, и сохранив обновленное состояние модели предметной области (в данном случае экземпляр dinner и его набор RSVP); после этого он возвращает ответ OK:

Вспомните: я решил, что у класса Dinner не должно быть зависимости от системных часов, и предпочел передавать текущее время в его метод. В контроллере я передаю _systemClock.Now как параметр currentDateTime. Это локальное поле, заполняемое через DI, что избавляет и контроллер от жесткого связывания с системными часами. Использовать DI в контроллере вполне разумно в противоположность сущности предметной области, так как контроллеры всегда создаются контейнерами сервисов ASP.NET; это подключает любые зависимости, объявленные контроллером в его конструкторе. Поле _systemClock имеет тип IDateTime, что определяется и реализуется всего несколькими строками кода:

Конечно, мне также нужно сконфигурировать контейнер ASP.NET так, чтобы он использовал MachineClockDateTime всякий раз, когда классу требуется экземпляр IDateTime. Это делается в ConfigureServices класса Startup, и, хотя подойдет любой жизненный цикл объекта, в данном случае я предпочел использовать Singleton, так как один экземпляр MachineClockDateTime будет обслуживать все приложение:

Включив эту простую абстракцию, я могу тестировать поведение контроллера в зависимости от того, передан ли крайний срок для RSVP, и гарантировать возврат корректного результата. Поскольку у меня уже есть тесты для метода Dinner.AddRsvp, проверяющие корректность его поведения, мне не понадобится очень много тестов для проверки того же поведения через контроллер, чтобы быть уверенным, что при совместной работе контроллер и модель предметной области функционируют правильно.

Следующие шаги

Скачайте сопутствующий этой статье проект-пример и посмотрите модульные тесты для Dinner и DinnersController. Помните, что свободно связанный код, как правило, гораздо проще в модульном тестировании, чем жестко связанный код, напичканный ключевыми словами new или вызовами статических методов, зависящих от обязанностей инфраструктуры. «New является связующим», так что ключевое слово new следует использовать в приложении осознанно, а не по воле случая. Узнать больше о ASP.NET Core и ее поддержке встраивания зависимостей можно на docs.asp.net.

Стив Смит (Steve Smith) — независимый тренер, преподаватель и консультант, а также обладатель звания ASP.NET MVP. Написал десятки статей для официальной документации ASP.NET Core (docs.asp.net) и работает с группами, осваивающими эту технологию. С ним можно связаться через сайт ardalis.com, также следите за его заметками в Twitter (@ardalis).

Выражаю благодарность за рецензирование статьи эксперту Microsoft Дугу Бантингу (Doug Bunting).

Илон Маск рекомендует:  Что такое код msql_fieldlen
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL