Любая технологическая платформа предлагает разработчику определенные стиль и подходы к разработке приложений. При условии расширяемости платформы и достаточном опыте ее использования разработчику не составит большого труда самостоятельно реализовать любой желаемый подход к разработке веб-приложений, тем не менее в большинстве случаев использование собственных возможностей платформы является наиболее предпочтительным с точки зрения скорости разработки и простоты дальнейшей поддержки решения.
Известный факт, что возможность выбора порождает проблему этого самого выбора — поэтому с появлением на платформе ASP.NET подхода к созданию веб-приложений MVC Framework у разработчиков возникает логичный вопрос — какой подход выбрать и какой подход будет наиболее оправдан при создании очередного веб-приложения. Не хотелось бы расстраивать читателя, жаждущего быстрого ответа на вопрос, какой подход избрать — WebForms или MVC Framework, но все же придется это сделать — ответом на вопрос, стоит ли выбрать MVC Framework для вашего следующего веб-приложения, является вся эта книга.
Существует необозримое множество технологий (и для разных задач лучше подходит та или иная технология) и сделать правильный выбор позволяет только достаточное знание возможностей, преимуществ и недостатков рассматриваемых технологий.
В этой главе проводится краткое сравнение технологий MVC Framework и WebForms, демонстрируется реализация подхода MVC на основе WebForms, что может быть полезно разработчикам, знакомым с WebForms, для того чтобы быстро освоиться с концепцией MVC, а также предлагаются некоторые советы по выбору той или иной технологии.
Сравнение WebForms и MVC Framework
Для того чтобы дать рекомендации по выбору той или иной технологии разработки веб-приложений, рассмотрим сильные и слабые стороны каждой из этих технологий, а также основные принципы, на которых основаны эти технологии.
Технология WebForms
Технология WebForms в ASP.NET была создана для того, чтобы сделать веб-разработку максимально простой для разработчика, знакомого с созданием клиентских приложений на Windows-платформе. По большому счету, создание WebForms мало отличается от создания настольных приложений — элементы управления, использующие механизмы обработки пользовательских действий и хранения состояния, позволяют применять для разработки визуальный подход. Разработчику достаточно разместить элементы управления на странице и определить логику их совместной работы, без необходимости глубокой работы с разметкой HTML и стилями CSS.
Технология WebForms значительно снизила "порог входа" в веб-разработку. Как в свое время появление визуальных средств разработки вроде Visual Basic дало возможность разработчикам разного уровня создавать приложения различной сложности, так появление технологии WebForms привело к быстрому росту количества динамических веб-приложений. Прежде всего, за счет возможности быстрого изучения технологии и быстрого старта разработки полнофункциональных приложений.
Модель расширения WebForms позволила большому количеству компаний разрабатывать собственные элементы управления, которые позволили существенно упростить и ускорить разработку веб-приложений. Кроме того, декларативный подход технологии WebForms позволяет очень просто преобразовывать классические веб-приложения для использования новейших технологий, таких как Ajax и Silverlight.
Преимущества WebForms
□ Высокая скорость разработки. Благодаря декларативному использованию компонентов и визуальному созданию веб-страниц, достигается высокая скорость разработки функционала веб-приложений. Использование готовых компонентов, интегрируемых между собой, позволяет очень быстро создать работающий прототип приложения, которое в дальнейшем дорабатывается до желаемого результата.
□ Большое количество готовых компонентов. В состав .NET Framework входит несколько десятков компонентов для реализации наиболее частых сценариев, а готовые компоненты третьих компаний позволяют сократить время на разработке и отладке собственных решений.
□ Богатая поддержка средствами разработки. Поддержка WebForms визуальными инструментами разработки, такими как Visual Studio и Expression Web, предоставляет возможность визуального проектирования интерфейса и создания базовых связей между элементами управления. Значительная часть разработки интерфейса приложения может быть выполнена веб-дизайнером, без привлечения разработчика.
□ Автоматическое управление состоянием. Состояние элементов управления на стороне клиента поддерживается автоматически, и разработчику нет необходимости отслеживать инициализацию всех элементов управления страниц между отправками данных на сервер (postback).
□ Событийная модель элементов управления. Механизмы обработки клиентских событий позволяют создавать обработчики событий на стороне сервера, разбивая общий код логики взаимодействия веб-страницы с пользователем на небольшие логические блоки.
□ Высокая степень абстракции над HTML-разметкой. Разработчику нет необходимости работать со страницей на уровне HTML-разметки. Элементы управления создают необходимую разметку во время генерации разметки для конечного пользователя. Кроме того, абстракция над разметкой позволяет генерировать разметку в зависимости от браузера, используемого для доступа к веб-приложению, что особенно важно для приложений, используемых на мобильных устройствах.
□ Простота изучения технологии. Общий набор концепций, делающий разработку веб-приложений похожей на разработку настольных приложений, и высокая степень абстракции над нижележащими технологиями позволяют быстро приступить к созданию веб-приложений.
□ Возраст технологии. В современном быстро меняющемся мире десяток лет — это уже очень много. За время существования WebForms было выработано множество методик создания веб-приложений, продуманы различные сценарии использования технологии и накоплен большой опыт в сообществах разработчиков.
Недостатки WebForms
□ Связка разметки и логики страницы. Разметка страницы, определенная в ASPX-файле, жестко привязана к коду логики, определенному в codebehind-файле, поскольку на основании разметки генерируется частичный класс, являющийся частью класса, определенного в code-behind-файле. В терминах MVC получается, что логика компонентов контроллера и представления смешиваются. Особенно в случае использования элементов, декларативно работающих с данными, таких как SqlDataSource/DataGrid, смешивается бизнес-логика, логика интерфейса и работы с данными.
□ Отсутствие полного контроля над конечной разметкой страницы. Поскольку в технологии WebForms генерация HTML-кода отдана на уровень элементов управления, разработчик не имеет полного контроля над финальной разметкой страницы, загружаемой в браузер пользователя. В большинстве случаев это не является проблемой, пока не возникает необходимости создавать большое количество клиентского кода, работающего с моделью документа HTML-страницы — в этом случае создание обходных путей может занять недопустимо много времени.
□ Сложность тестирования логики приложения . Поскольку есть связка интерфейса с бизнес-логикой, тестирование логики приложения в отрыве от интерфейса затруднено, что усложняет автоматическое тестирование и требует использования инструментов, позволяющих эмулировать действия пользователя на интерфейсе приложения. Это становится критичным, когда для выполнения тестов через пользовательский интерфейс требуется неоправданно большое время, а для успешного тестирования необходимо частое повторное проведение тестов.
□ Неестественная для веб-среды модель сохранения состояния. Модель событий и хранения состояния, являющаяся преимуществом WebForms и позволяющая создавать веб-приложения по образу и подобию настольных приложений, является и недостатком этой модели. HTTP-протокол не поддерживает состояния и, при попытке это состояние добавить в жизненный цикл приложения, приходится создавать нагромождения дополнительного слоя логики, отвечающего за работу с состоянием. При использовании большого количества элементов на странице скрытое поле ViewState, используемое для хранения состояния между отправками данных формы на сервер, может достигать больших размеров, существенно влияя на скорость передачи данных между сервером и клиентом. В этом случае разработчику приходится приложить дополнительные усилия по оптимизации хранимых данных о состоянии, использовать другие механизмы для хранения состояния и так или иначе вмешиваться в стандартную модель WebForms.
Технология MVC Framework
В главе 1 были перечислены некоторые преимущества архитектурного подхода MVC и реализации в MVC Framework. Здесь же мы подробнее остановимся на достоинствах и недостатках MVC Framework в сравнении с WebForms.
Преимущества MVC Framework
□ Четкое разделение логических слоев. Отделение представления от контроллера предоставляет возможность простой замены движка представления без модификации кода контроллера, независимость от реализации модели позволяет описать только интерфейсы объектов и подменять реализацию при необходимости.
□ Полный контроль над разметкой. Возможность получить "чистый" HTML-код значительно упрощает разработку и поддержку клиентского JavaScript-кода.
□ Логическое разделение функциональности. В веб-приложениях MVC есть четкое разделение на действия контроллеров, и каждое действие имеет собственный URI. В случае WebForms страница может инкапсулировать различную логику работы страницы и сохранять тот же самый URI, например Default.aspx, при выполнении операций со страницей. В MVC-приложении разные действия, инициируемые страницей, соответствуют различным действиям контроллера. Так, например, метод Edit контроллера возвращает страницу, а метод Update используется для обновления данных и отображения сообщения об изменении данных.
□ "Красивые" URL-адреса. Поскольку MVC Framework предполагает использование гибкой системы маршрутизации, пользователь получает удобные и понятные URL-адреса страниц в виде /Products/List, /Products/Edit/1 и т. п.
□ Прозрачный процесс обработки запроса. Жизненный цикл страницы в WebForms описывается механизмом событий, этот механизм легко расширяется и позволяет добавлять расширенную функциональность в страницу без модификации кода самой страницы — через глобальные обработчики HttpModule на события той или иной страницы может быть подписан внешний обработчик. Однако в больших и сложных системах наличие множества обработчиков страницы делает процесс обработки запроса нелинейным и сложным для отладки. Кроме того, для успешной работы со страницами в WebForms разработчику нужно очень хорошо представлять последовательность выполнения действий по инициализации инфраструктуры страницы, для того чтобы вносить необходимые модификации в общее течение процесса обработки страницы. В случае MVC Framework процесс обработки запроса легко прослеживается, поскольку обработка запроса разделена на небольшое количество очень простых шагов.
□ Поддержка различных движков генерации разметки. Компоненты представления, входящие в поставку MVC Framework, могут быть легко заменены на написанные самостоятельно либо разработанные другими разработчиками. В проекте MVCContrib (http://www.codeplex.com/MVCContrib) доступны альтернативные движки представления, такие как Brail, NHaml, NVelocity и XSLT.
□ Полноценная поддержка всех возможностей платформы ASP.NET. Применяя MVC Framework, разработчик может использовать все возможности платформы ASP.NET точно так же, как и разработчик, использующий WebForms. MVC Framework не ограничивает использование стандартных служб ASP.NET, таких как Session, Cache, Membership, Profile, Roles и т. п.
Недостатки MVC Framework
□ Более высокий "порог входа" в технологию. Разработчику, только начинающему осваивать создание веб-сайтов, потребуется достаточно подробное изучение веб-технологий, таких как HTML, CSS и JavaScript, для успешного создания многофункциональных веб-приложений. Если технология WebForms во многом "экранирует" разработчика от веб-среды, предоставляя высокую степень абстракции над веб-страницами, то MVC Framework сразу же требует достаточно глубокого понимания веб-технологий.
□ Отсутствие механизма хранения состояния. MVC Framework не предлагает механизма хранения состояния, и разработчику необходимо реализовывать его самостоятельно, используя скрытые поля, cookie-файлы или хранение данных в URL.
□ Сложности создания библиотек компонентов. Отсутствие механизма элементов управления, присутствующего в WebFroms, затрудняет создание компонентов для повторного использования. При существующем подходе к созданию представлений инкапсуляция полной логики повторно используемого компонента в отдельную сборку затруднена.
□ Молодость технологии. Поскольку релиз MVC Framework вышел всего за несколько месяцев до момента написания этих строк, сообщество разработчиков не накопило еще того опыта, который накоплен с WebForms, а компании-разработчики компонентов еще не создали такого большого количества расширений для MVC Framework, как в случае с WebForms.
Выбор подхода к разработке веб-приложения
На платформе ASP.NET можно создать любое веб-приложение, с любым уровнем сложности и возможностями по масштабированию, несмотря на выбранный подход, однако правильный выбор подхода позволит достичь результата меньшими усилиями и упростить дальнейшую поддержку проекта. Приступая к проектированию очередного веб-приложения, вы, возможно, задумаетесь о выборе подхода WebForms или MVC Framework.
Как уже было сказано ранее, такой выбор можете сделать только вы, основываясь на своих знаниях технологии WebForms и MVC Framework, исходя из требований того самого приложения, над которым вы размышляете. Тем не менее постараемся сформулировать список требований, который может пригодиться при выборе между WebForms и MVC Framework. Требования с краткими комментариями приведены в табл. 2.1. Большинство приведенных требований весьма условны и предназначены лишь для того, чтобы дать читателю пищу для размышлений.
Рассмотрев приведенные в табл. 2.1 требования, можно грубо определить, насколько MVC Framework может быть использована для решения конкретной поставленной задачи.
Нужно отметить еще один важный принцип, который может быть полезен при выборе технологии: предыдущий опыт разработки участников команды, которая будет работать над новым проектом. В случае если у членов команды был опыт создания приложений с использованием платформы PHP, Ruby, Perl и т. п., то очевидным выбором будет MVC Framework, однако если члены команды имеют большой опыт разработки с использованием WebForms или JSP, то переход на MVC Framework может быть для них достаточно длительным, поскольку работа с технологиями вроде WebForms вырабатывает определенный стиль кодирования, и для упрощения разработки и поддержки могут быть использованы различные архитектурные подходы (например, такие как Web Client Software Factory от команды Patters & Practices в Microsoft). MVC Framework навязывает общую архитектуру и подход к написанию кода веб-приложения, а привычки достаточно сложно изменить. Поэтому, если сроки сдачи проекта небольшие, а в команде в основном программисты, знакомые с WebForms, данный аргумент может пересилить все остальные, приведенные ранее.
Реализация подхода MVC в WebForms
Продемонстрируем подход MVC для разработчиков, знакомых с технологией WebForms, выделив логику обработки страницы в контроллер, а саму страницу используя как компонент представления и модель, описывающую данные, размещаемые на странице.
Рассмотрим ASPX-страницу, приведенную в листинге 2.1. На этой странице размещены несколько элементов управления Label, TextBox и Button. Логика страницы должна быть простой, и в классической модели WebForms описывается в code-behind-файле, код которого приведен в листинге 2.2.
Листинг 2.1. Страница Default.aspx
<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs" Inherits="WebFormsMvc._Default" %>
" http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">
Листинг 2.2. Файл Default.aspx.cs
using System;
using WebFormsMvc.Controllers;
namespace WebFormsMvc {
{
protected void btnSave_Click(object sender, EventArgs e) {
lblResponse.Text = txtFirstName.Text + " "
+ txtLastName.Text; }
}
}
Для того чтобы выделить отдельный компонент контроллер, который будет отвечать за логику обработки запросов к странице, таких, например, как щелчок по кнопке или загрузка первоначальных значений в текстовые поля, необходимо обеспечить возможность контроллера модифицировать модель, отображением которой является представление. В случае ASPX-страницы моделью является собственно сама объектная модель страницы, поэтому именно к ней нужно предоставить доступ контроллеру — для этого достаточно отредактировать CS-файл, автоматически создаваемый Visual Studio для страницы, и сделать все поля, соответствующие элементам управления на форме, публичными, как это приведено в листинге 2.3.
Листинг 2.3. Модифицированный файл Default.aspx.designer.cs
namespace WebFormsMvc {
public partial class _Default {
public global::System.Web.UI.HtmlControls.HtmlForm form1;
public global::System.Web.UI.WebControls.Label lblResponse;
public global::System.Web.UI.WebControls.TextBox txtFirstName;
public global::System.Web.UI.WebControls.TextBox txtLastName;
public global::System.Web.UI.WebControls.Button btnSave;
}
}
После этого можно создать отдельный класс-контроллер для страницы Default.aspx, код которого приведен в листинге 2.4, и обращаться к нему из обработчиков событий страницы, как это показано в листинге 2.5. Обработчики событий страницы, в данном случае, выполняют только утилитарную роль привязки вызовов методов контроллера к событиям страницы.
Листинг 2.4. Файл DefaultPageControNer.cs
namespace WebFormsMvc.Controllers {
public class DefaultPageController {
public DefaultPageController(_Default pg) { page = pg; }
public void ButtonSaveClick()
{
page.lblResponse.Text = page.txtFirstName.Text + " "
+ page.txtLastName.Text;
}
public void PageLoad()
{
if (!page.IsPostBack)
{
page.txtFirstName.Text = "Иван";
page.txtLastName.Text = "Кузнецов";
}
}
}
}
Листинг 2.5. Модифицированный файл Default.aspx.cs
using System;
using WebFormsMvc.Controllers;
namespace WebFormsMvc {
public partial class _Default:System.Web.UI.Page {
protected DefaultPageController controller;
protected void btnSave_Click(object sender, EventArgs e)
{
controller.ButtonSaveClick();
}
protected void Page_Load(object sender, EventArgs e)
{
controller = new DefaultPageController(this);
controller.PageLoad();
}
}
Теперь, когда логика страницы вынесена в отдельную сущность — контроллер, есть возможность тестирования логики в отрыве от представления. Для этого достаточно создать экземпляр класса контроллера и передать ему проинициализированный объект модели. Поскольку в качестве модели выступает ASPX-страница, необходимо создать экземпляр класса страницы и про-инициализировать значащие элементы управления, поскольку при тестировании не будут задействованы внутренние механизмы создания экземпляров страниц.
В листинге 2.6 приведен простейший unit-тест для проверки обработчика события загрузки страницы.
Листинг 2.6. Unit-тест для события загрузки страницы
[TestMethod]
public void TestPageLoad()
_Default page = new _Default();
page.txtFirstName = new TextBox();
page.txtLastName = new TextBox();
DefaultPageController controller = new DefaultPageController(page);
controller.PageLoad();
Assert.AreEqual(page.txtLastName.Text, "Кузнецов");
}
Развивая это решение, можно пойти дальше и для упрощения разработки и тестирования для всех страниц создать интерфейсы, описывающие модель. В этом случае на этапе создания unit-тестов можно будет работать со специальными тестовыми экземплярами модели, автоматически инициализирующими нужные поля при создании, не прибегая к созданию экземпляров класса страницы и написанию большого количества кода в unit-тестах.
Указанный ранее подход может быть применен в веб-приложениях, использующих подход WebForms, с целью упрощения тестирования, однако использование такого подхода не упрощает миграцию на MVC Framework. Поэтому, если вы проектируете приложение на WebForms, но подумываете над будущей миграцией на MVC Framework, лучший совет для вас — откажитесь от планов миграции, либо сразу же пишите на основе MVC Framework.
Совмещение WebForms и MVC Framework в рамках одного веб-приложения
Обидно терять наработки, особенно когда они еще могут пригодиться и сохранить большое количество времени на разработку нового функционала. И еще более обидно, когда есть технология, которая просто идеально подходит для решения поставленной задачи, однако существующее решение уже построено на другой технологии, его необходимо развивать, а времени переписать все заново нет.
В этих случаях можно подумать над совмещением технологий WebForms и MVC Framework, возможно, несколько жертвуя принципами архитектуры MVC.
Использование элементов управления WebForms в MVC-приложениях
Поскольку в MVC Framework в качестве движка представлений по умолчанию используется стандартный механизм ASPX-страниц, то можно попробовать использовать существующие элементы управления на MVC-страницах. Однако нужно помнить о том, что для представлений в MVC-приложениях не работает стандартный механизм обработки событий, и элементы управления теряют свои серверные возможности по обработке событий. Поэтому для подобного использования пригодны элементы управления, представляющие ценность на этапе первоначальной генерации разметки, отправляемой пользователю, такие как, например, Repeater или GridView.
Чтобы продемонстрировать эту возможность, используем декларативный источник данных sqlDataSource и GridView в представлении Index.aspx, в результате получим страницу, приведенную на рис. 2.1. Код страницы приведен в листинге 2.7.
Листинг 2.7. Страница Index.aspx
<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage" %>
runat="server">
Home Page
runat="server">
<%= Html.Encode(ViewData["Message"]) %>
Результат обращения к действию Index контроллера Home представлен на рис. 2.2. Если, к примеру, включить возможность сортировки в GridView, после чего щелкнуть по ссылке в заголовке таблицы, то будет отображена ошибка, представленная на рис. 2.3, поскольку MVC Framework не позволяет корректно обработать серверные события.
Очевидно, что указанные ограничения функциональности элементов управления делают подобное использование элементов управления, требующих обработки серверных событий, непригодными для использования в представлениях. Для таких элементов управления стоит рассмотреть методику внедрения полноценных WebForms-страниц в MVC-приложение.
С другой стороны, для элементов, отвечающих только за генерацию разметки, такое использование может быть оправдано.
Внедрение страниц WebForms в MVC-приложения
Чтобы использовать страницу WebForms в MVC-приложении, нет необходимости писать большое количество кода. Поскольку MVC-приложение по сути является ASP.NET-приложением, и при его создании нет препятствий к использованию WebForms, все, что нужно сделать — объяснить системе маршрутизации MVC Framework, что для страниц WebForms эту самую систему маршрутизации использовать не надо. Для этого достаточно добавить в файле Global.asax в метод RegisterRoutes правило для игнорирования путей к страницам ASPX:
routes.IgnoreRoute("{resource}.aspx/{"pathInfo}");
После этого в MVC-приложение можно добавить стандартную ASPX-страницу, например WebForm1.aspx, код которой приведен в листинге 2.8, и для этой страницы будет обеспечена полноценная функциональность WebForms, что подтверждает рис. 2.4.
Листинг 2.8. Страница WebForml.aspx
<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="WebForm1.aspx.cs"
Inherits="MvcWebFormsCompositeApp.WebForm1" %>
" http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">
Использование MVC Framework в существующих решениях WebForms
Рассмотрим сценарий расширения существующего WebForms-приложения с использованием MVC Framework. Для этого нужно выполнить несколько простых шагов:
1. Установить в свойствах веб-приложения версию .NET Framework 3.5, поскольку если приложение WebForms было разработано для версии .NET Framework 2.0, то MVC Framework для нее не поддерживается.
2. Добавить ссылки на сборки System.Web.Mvc и System.Web.Routing.
3. Зарегистрировать в файле web.config необходимые для функционирования MVC-приложения обработчики в разделе system.web/httpModules (листинг 2.9) и system/webServer/modules и system/webServer/handlers (листинг 2.10). Необходимые изменения выделены полужирным. Кроме того, поскольку в листингах 2.9 и 2.10 сборки указываются без описания версий, необходимо в директорию bin веб-приложения скопировать файлы System.Web.Mvc.dll и System.Web.Routing.dll. Либо указать полные имена сборок, посмотрев описания в тестовом MVC-приложении, которое стоит создать по такому случаю.
4. Зарегистрировать пространства имен, которые будут использовать представления (листинг 2.11).
5. Создать таблицу маршрутизации в файле global.asax (листинг 2.12).
6. Создать директорию /Controllers, разместить в ней контроллеры.
7. Создать директорию /Views и разместить в ней дерево представлений, отвечающее контроллерам и их действиям (рис. 2.5).
Листинг 2.9. Регистрация модуля MVC Framework в web.config
type=" System.Web.Routing.UrlRoutingModule,
System.Web.Routing" />
type="System.Web.Handlers.ScriptModule,
System.Web.Extensions"/>
Листинг 2.10. Регистрация модулей и обработчиков MVC Framework в web.config
type="System.Web.Handlers.ScriptModule,
System.Web.Extensions"/>
System.Web.Routing" />
path="*.asmx" preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions"/>
path="*_AppService.axd" preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions"/>
verb="GET,HEAD" path="ScriptResource.axd"
type="System.Web.Handlers.ScriptResourceHandler,
System.Web.Extensions" />
path=" *.mvc" type=" System.Web.Mvc.MvcHttpHandler,
System.Web.Mvc"/>
verb="*" path="UrlRouting.axd"
type="System.Web.HttpForbiddenHandler, System.Web" />
Листинг 2.11. Регистрация пространств имен в файле web.config
Листинг 2.12. Таблица маршрутизации в файле Global.asax
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}") ;
routes.IgnoreRoute("{resource}.aspx/{*pathInfo}");
routes.MapRoute("Default", "{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = "" });
}
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
}
Рис. 2.5. Структура WebForms-приложения после добавления MVC-компонентов
После того как все необходимые шаги выполнены, можно продолжать пользоваться WebForms-приложением, а также использовать только что добавленные контроллер и представление, например, создав контроллер Home (листинг 2.13) и представление Index (листинг 2.14), можно получить при обращении по пути /Home/Index результат, представленный на рис. 2.6.
Листинг 2.13. Файл HomeController.cs
using System.Web.Mvc;
namespace WebFormsMvcInterop.Controllers {
public class HomeController : Controller {
public ActionResult Index()
{
return View();
}
}
}
Листинг 2.14. Файл Index.aspx
<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>
EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Hello from MVC
Заключение
В этой главе мы рассмотрели достоинства и недостатки MVC Framework в сравнении с WebForms, а также возможности совместного использования этих технологий в рамках одного проекта. Пожалуй, нужно отметить, что не стоит смешивать эти технологии без необходимости, поскольку при совмещении WebForms и MVC Framework вы получаете все их недостатки, не всегда имея возможность полностью реализовать достоинства.
Этой главой мы заканчиваем несколько растянувшееся введение, и, начиная со следующей главы, вы сможете глубоко окунуться в технические детали использования MVC Framework.