ASP_NET_MVC_4_Framework_s_primerami_na_C_dlya_p

Между определением LINQ выборки и перечислением результатов мы изменили один из элементов массива products. Результат этого примера выглядит следующим образом:

Price: 79600 Price: 275 Price: 48.95

Вы видите, что запрос не обрабатывается до получения результатов перечисления, и поэтому изменение, которое мы сделали – введение Stadium в массив Product – отображается в выходных данных.

Совет

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

В отличие от этого, использование любого из не отложенных (nondeferred) методов расширения приводит к тому, что выборка LINQ выполняется немедленно. В листинге 4-31 показан метод действия SumProducts, которые мы добавили в контроллер Home.

Листинг 4-31: Немедленно выполняемая выборка LINQ

public ViewResult SumProducts()

{

Product[] products = {

new Product {Name = "Kayak", Category = "Watersports", Price = 275M},

new Product {Name = "Lifejacket", Category = "Watersports", Price = 48.95M}, new Product {Name = "Soccer ball", Category = "Soccer", Price = 19.50M}, new Product {Name = "Corner flag", Category = "Soccer", Price = 34.95M}

};

var results = products.Sum(e => e.Price);

products[2] = new Product { Name = "Stadium", Price = 79500M };

return View("Result", (object)String.Format("Sum: {0:c}", results));

}

В этом примере используется метод Sum, который является не отложенным и выдает следующий результат:

Sum: $378.40

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

LINQ и интерфейс IQueryable<T>

Можно повстречать различные вариации LINQ, хотя используется он всегда практически одинаково. Одной из разновидностей является LINQ to Objects, и эту разновидность мы использовали в примерах данной главы. LINQ to Objects позволяет делать выборку C# объектов, которые находятся в памяти. Другая разновидность, LINQ to XML – это очень удобный и мощный способ создания, обработки и выборки XML содержания. Параллельный LINQ (Parallel LINQ, PLINQ) является расширенной версией LINQ to Object, которая поддерживают выполнение LINQ выборок одновременно на нескольких процессорах или ядрах.

92

Особый интерес для нас представляет LINQ to Entities, который позволяет делать LINQ запросы к данным, полученным из Entity Framework. Entity Framework является ORM фреймворком Microsoft, представляющий собой часть более широкой платформы ADO.NET. ORM позволяет работать с реляционными данными при помощи C# объектов. И это тот механизм, который мы будем использовать в данной книге для доступа к данным, хранящимся в базах данных. Вы увидите, как используются Entity Framework и LINQ to Entities, в главе 4. Но мы также хотели упомянуть интерфейс IQueryable<T> во время представления LINQ.

Интерфейс IQueryable<T> является производным от IEnumerable<T> и используется для обозначения результата выборки, выполненной в отношении конкретного источника данных. В наших примерах это будет база данных SQL Server. Вообще, нет необходимости использовать IQueryable<T> напрямую. Одна из приятных особенностей LINQ заключается в том, что одна и та же выборка может быть выполнена для нескольких типов исходных данных (объектов, XML, баз данных и т. д.). Когда вы увидите, что мы используем IQueryable<T> в примерах дальнейших глав, то вы поймете, что мы делаем это, чтобы было ясно, что мы имеем дело с данными, которые приходят из базы данных.

Использование асинхронных методов

Одним из самых серьезных дополнений C# в .NET 4.5 является улучшенный способ работы асинхронных методов. Асинхронные методы скрыты и работают в фоновом режиме, а затем они уведомляют вас, когда завершают свою работу, что позволяет коду выполнять другие задачи, пока идет работа в фоновом режиме. Асинхронные методы являются важным инструментом в устранении узких мест в коде и позволяют приложениям работать параллельно на нескольких процессорах и процессорных ядрах.

C# и. NET отлично поддерживают асинхронные методы, но тогда код становится немного громоздким, и разработчики, которые не привыкли к параллельному программированию, часто вязнут в необычном синтаксисе. В качестве простого примера в листинге 4-32 представлен асинхронный метод, который называется GetPageLength. Мы определили его в классе

MyAsyncMethods и добавили в папку Models.

Листинг 4-32: Простой асинхронный метод

using System.Net.Http;

using System.Threading.Tasks; namespace LanguageFeatures.Models

{

public class MyAsyncMethods

{

public static Task<long?> GetPageLength()

{

HttpClient client = new HttpClient();

var httpTask = client.GetAsync("http://apress.com");

//мы можем здесь делать другие вещи, пока мы ждем

//окончания HTTP запроса

return httpTask.ContinueWith((Task<HttpResponseMessage> antecedent) =>

{

return antecedent.Result.Content.Headers.ContentLength; });

}

}

}

Это простой метод, который использует объект System.Net.Http.HttpClient для запроса содержимого страницы Apress и возвращает ее длину. Мы выделили ту часть метода, которая может привести к путанице, что является примером возобновления задачи.

93

.NET будет работать асинхронно используя Task. Объекты Task строго типизированы и основываются на результате, который возвращает работа в фоновом режиме. Так что когда мы вызываем метод HttpClient.GetAsync, то, что нам вернется, будет Task<HttpResponseMessage>.

Это говорит нам о том, что запрос будет выполняться в фоновом режиме и о том, что результат запроса будет объектом HttpResponseMessage.

Совет

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

Та часть, в которой могут увязнуть большинство программистов, это возобновление задачи. Это механизм, при помощи которого вы указываете, что должно произойти, когда будет выполнена фоновая задача. В этом примере мы использовали метод ContinueWith для обработки объекта HttpResponseMessage который мы получаем от метода HttpClient.GetAsync. Это мы сделали при помощи лямбда-выражения, которое возвращает значение свойства, возвращающего длину контента, которой мы получили от веб-сервера Apress. Обратите внимание, что мы дважды используем ключевое слово return:

return httpTask.ContinueWith((Task<HttpResponseMessage> antecedent) => { return antecedent.Result.Content.Headers.ContentLength;

});

Это та часть, которая доставляет головную боль. Первое использование ключевого слова return указывает на то, что мы возвращаем объект Task<HttpResponseMessage>, который после выполнения задачи вернет (будет использовать return) длину заголовка ContentLength. Заголовок ContentLength возвращает результат long?, и это обозначает, что результат нашего метода GetPageLength будет Task<long?>:

public static Task<long?> GetPageLength() {

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

Применение ключевых слов async и await

Microsoft представил два новых ключевых слова в C#, которые специально предназначены для упрощения использования асинхронных методов, таких как HttpClient.getAsync. Новые ключевые слова – это async и await, и вы можете увидеть в листинге 4-33, как мы использовали их для упрощения нашего примера.

Листинг 4-33: Использование ключевых слов async и await

using System.Net.Http;

using System.Threading.Tasks; namespace LanguageFeatures.Models

{

public class MyAsyncMethods

{

94

public async static Task<long?> GetPageLength()

{

HttpClient client = new HttpClient();

var httpMessage = await client.GetAsync("http://apress.com");

//мы можем здесь делать другие вещи, пока мы ждем

//окончания HTTP запроса

return httpMessage.Content.Headers.ContentLength;

}

}

}

Мы использовали ключевое слово await при вызове асинхронного метода. Это говорит компилятору C#, что мы хотим подождать результат Task, который возвращает метод GetAsync, а затем продолжить выполнение других операторов в том же методе.

Применение ключевого слова await обозначает, что мы можем обрабатывать результат, полученный из метода GetAsync, как будто это обычный метод, и просто присвоить объект HttpResponseMessage, который он возвращает, переменной. И что еще лучше, мы можем использовать ключевое слово return в обычном порядке для получения результата от другого метода, в данном случае, значение свойства ContentLength. Это гораздо более естественный способ, и это обозначает, что мы не должны беспокоиться о методе ContinueWith и многократном использовании ключевого слова return.

При использовании ключевого слова await необходимо также добавлять ключевое слово async в описание метода, как мы это сделали в нашем примере. И тип, возвращенный методом, не изменится: наш метод из примера GetPageLength по-прежнему возвращает Task<long?>. Это происходит потому, что await и async реализованы при помощи некоторых классных уловок компилятора. То есть, они позволяют нам использовать более естественный синтаксис, но они не меняют то, что происходит в методах, к которым они применяются. Кто-то, кто вызывает наш метод GetPageLength, по-прежнему имеет дело с результатом Task<long?>, потому что существует фоновое действие, результатом которого является значение long?. Хотя, конечно, программисты сами выбирают, использовать ли им await и async.

Примечание

Возможно, вы заметили, что мы не предоставили MVC примера для тестирования ключевых слов async и await. Это потому что использование

асинхронных методов в MVC контроллерах требует специальных технических навыков. И до главы 17 мы дадим вам еще много полезной информации по этой теме.

Резюме

В этой главе мы начали с обзора ключевых функций языка C#, о которых должны знать эффективные MVC программисты. Эти функции объединены в LINQ, который мы будем использовать для выборки данных в этой книге. Как мы уже говорили, мы большие поклонники LINQ, и он играет важную роль в MVC приложениях. Мы также показали вам ключевые слова async и await, которые облегчают работу с асинхронными методами: это тема, к которой мы вернемся в главе 17, когда мы покажем вам передовые технические приемы для интеграции асинхронного программирования с вашими MVC контроллерами.

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

95

Работа с Razor

Razor – это движок представления, который Microsoft представил в MVC 3 и который был немного переделан в MVC 4 (хотя изменения являются относительно незначительными). Движок представления обрабатывает ASP.NET контент и ищет инструкции, как правило, для вставки динамического контента в выходные данные, отправленные браузеру. Microsoft поддерживает два вида движков: движок ASPX работает с тегами <% и %>, которые являлись основой развития ASP.NET в течение многих лет. А движок Razor, который работает с отдельными областями контента, обозначается символом @.

По большому счету, если вы знакомы с синтаксисом <% %>, Razor не доставит слишком много проблем, хотя и есть несколько новых правил. В этом разделе мы дадим вам краткий обзор синтаксиса Razor, так что вы сможете распознать новые элементы, когда вы их встретите. Мы не собираемся углубленно изучать Razor в этой главе, скорее это ускоренный курс синтаксиса. Более подробно мы изучим Razor далее в этой книге.

Совет

Razor тесно связаны с MVC, но с появлением ASP.NET 4.5 движок представления Razor также поддерживает ASP.NET Web Pages.

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

Для демонстрации возможностей и синтаксиса Razor мы создали новый проект Visual Studio, используя шаблон ASP.NET MVC 4 Web Application и выбрав вариант Empty.

Определение модели

Мы будем использовать очень простую доменную модель и воспроизведем тот же доменный класс Product, который мы использовали в первой части книги. Добавьте файл класса Product.cs в папку Models и убедитесь, что содержание соответствует тому, что показано в листинге 5-1.

Листинг 5-1: Создание простого класса доменной модели

namespace Razor.Models

{

public class Product

{

public int ProductID { get; set; } public string Name { get; set; } public string Description { get; set; } public decimal Price { get; set; } public string Category { set; get; }

}

}

Определение контроллера

Чтобы добавить контроллер в проект, щелкните правой кнопкой мыши в вашем проекте по папке Controllers и выберите Add, а затем Controller, из всплывающего меню. Назовите его

HomeController и выберите Empty MVC Controller в опции Template, как показано на рисунке 5-1.

96

Рисунок 5-1: Создание ProductController

Нажмите кнопку Add, чтобы создать класс Controller, а затем измените содержимое файла, чтобы оно соответствовало листингу 5-2.

Листинг 5-2: Простой контроллер

using Razor.Models; using System;

using System.Collections.Generic; using System.Web.Mvc;

namespace Razor.Controllers

{

public class HomeController : Controller

{

Product myProduct = new Product

{

ProductID = 1,

Name = "Kayak",

Description = "A boat for one person", Category = "Watersports",

Price = 275M };

public ActionResult Index()

{

return View(myProduct);

}

}

}

Мы определили метод действия Index, в котором мы создаем и заполняем свойства объекта Product. Мы передаем Product методу View, поэтому он используется в качестве модели, когда

97

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

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

Чтобы создать представление, щелкните правой кнопкой мыши по методу Index класса HomeController и выберите Add View. Проверьте опцию, что создается строго типизированное представление и выберите класс из раскрывающегося списка Product, как показано на рисунке 5-2.

Примечание

Если вы не видите в раскрывающемся списке класс Product, скомпилируйте ваш проект и попробуйте создать представление еще раз. Visual Studio не распознает классы модели, пока они не скомпилированы.

Рисунок 5-2: Добавление представления

98

Убедитесь, что отключена опция для использования макета и мастер страницы (use a layout or master page), как показано на рисунке. Нажмите кнопку Add, чтобы создать представление, которое появится в папке Views/Home и будет называться Index.cshtml. Файл представления будет открыт для редактирования, и вы увидите, что это тот же базовый файл представления, который мы создавали в предыдущей главе, как показано в листинге 5-3.

Листинг 5-3: Простое Razor представление

@model Razor.Models.Product @{

Layout = null;

}

<!DOCTYPE html> <html>

<head>

<meta name="viewport" content="width=device-width" /> <title>Index</title>

</head>

<body>

<div>

</div>

</body>

</html>

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

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

Примечание

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

Работа с объектом модели

Давайте начнем с первой строки в представлении:

@model Razor.Models.Product

Операторы Razor начинаются с символа @. В данном случае выражение @model объявляет тип объекта модели, который мы передадим в представление из метода действия. Это позволяет нам обратиться к методам, полям и свойствам объекта модели представления через @Model, как показано в листинге 5-4. Здесь представлено простое дополнение к методу Index.

Листинг 5-4: Обращение к свойству объекта модели в Razor представлении

@model Razor.Models.Product @{

Layout = null;

99

}

<!DOCTYPE html> <html>

<head>

<meta name="viewport" content="width=device-width" /> <title>Index</title>

</head>

<body>

<div>

@Model.Name

</div>

</body>

</html>

Примечание

Обратите внимание, что мы объявили тип объекта модели представления при помощи @model (маленькая m), а получили доступ к свойству Name при помощи @Model (заглавная M). Это кажется немного запутанным, когда вы начинаете

работать с Razor, но вы очень быстро к этому привыкнете.

Если вы запустите проект, вы увидите результат, показанный на рисунке 5-3. Вам не нужно указывать конкретный URL, потому что по умолчанию в MVC проекте запрос для корневого URL (/) направляется к методу действия Index в контроллере Home, хотя мы покажем вам, как это изменить, в главе 13.

Рисунок 5-3: Результат прочтения значения свойства в представлении

При помощи выражения @model мы говорим MVC, с каким видом объекта мы будем работать, а Visual Studio использует это в несколькими способами. Во-первых, когда вы пишете код представления, Visual Studio покажет вам несколько вариантов, касательных имен членов объекта, если вы наберете @Model и поставите точку, как показано на рисунке 5-4. Это очень похоже на то, как работает автозаполнение для лямбда-выражений, которые передаются вспомогательным методам HTML, о чем мы рассказывали в главе 4.

100