Чистое программирование

Пишем CMS. Шаг № 8. Unit-тестирование

2010-03-30T16:43:00.000-07:00

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

1. Перво-наперво качаем последнюю версию NUnit (откуда, найдете сами).

2. Создаем в солюшене отдельный проект типа ClassLibrary и добавляем референс на библиотеку nunit.framework.dll, которая лежит в папке framework каталога, куда распаковался наш nunit.

3. Создаем новый класс, добавляем в него ссылку на пространство имен NUnit.Framework, затем перед классом добавляем атрибут [TestFixture], а перед методом-тестом (который должен быть обязательно public и возвращать void - атрибут [Test].

4. Теперь надо организовать удобный запуск тестов. Я обычно делаю так. В окне свойств проекта с тестами щелкаю вкладку Debug, а там - Start external program, где указываю путь к nunit.exe. А сам проект устанавливаю как SetUp as statrup project. Это значит, что теперь, когда я нажимаю F5, запускается именно этот проект, вернее, запускается оболочка nunit.exe, которая подтягивает наши проекты.

5. Теперь надо создать проект среды тестирования. Для этого нажмем F5 и увидим диалог NUnit, там мы выберем меню New Project, введем название и сохраним проект где-нибудь (я предпочитаю корневую папку проекта с тестами). Теперь можно добавить туда нашу dll с тестами (она обычно лежит в bin/debug) - через меню Project - Add assembly (некоторые версии NUnit имеют такой баг - после того, как вы создаете проект и загружаете туда dll, он не подхватывает библиотеку, выдает какую-то странную ошибку. Если это произошло, просто сохраните проект и закройте оболочку, затем запустите снова - должно пройти.)

6. Ну вот и все! Теперь можете писать свои тесты и запускать их. Да! Одна маленькая, но очень важная деталь - если вы не обратите на это внимание, вы можете часами биться об стену, пытаясь понять, в чем дело. А дело в том, что если вы работаете например, с ADO.Net Entity Framework и вам надо потестировать, хорошо ли из базы забираются данные, то вы обязательно должны скопировать файл App.Config в папку проекта с тестами - именно отсюда фреймворк будет брать информацию по соединению с БД. Но и это еще не все. В свойствах NUnit проекта в поле Configuration File Name нужно обязательно указать имя этого конфигурационного файла.

Теперь, кажется, все... удачного тестирования!

Пишем CMS. Шаг № 7. Шаг вперед, два шага назад. Рефакторинг

2010-03-17T14:04:00.000-07:00

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

Добавим в ресурсный файл Messages переменную по имени TransferPageMessage, что-то вроде "Вы будете перемещены на страницу {0} через {1} сек. Или, если ваш браузер не поддерживает автоматическое перенаправление, перейдите по ссылке ниже:"

Изменим содержимое контрола:

<asp:Panel ID="panelInfo" runat="server" Visible="true"> <asp:Label ID="labInfo" runat="server" Text="" CssClass="LabelInfo"></asp:Label> <asp:Label ID="labLink" runat="server" CssClass="LabelInfo" Visible="false"></asp:Label> <asp:HyperLink ID="linkInfo" runat="server" CssClass="LinkInfo" Visible="false"> </asp:HyperLink> </asp:Panel> * This source code was highlighted with Source Code Highlighter.

А теперь обновим код:

public void ShowFail(string Message) { this.Visible = true; panelInfo.CssClass = "PanelInfoFail"; if (Message != string.Empty) labInfo.Text = Message; } public void ShowOk(string Message, string PageToName, string LinkLabelCode, string Link, int SecondsToTransfer) { this.Visible = true; panelInfo.CssClass = "PanelInfoOK"; if (Message != string.Empty) labInfo.Text = Message + "<br><br>"; if (PageToName != string.Empty) { labLink.Visible = true; labLink.Text = string.Format(Messages.TransferPageMessage, PageToName, SecondsToTransfer) + "<br><br>"; } if (LinkLabelCode != string.Empty && Link != string.Empty) { linkInfo.Visible = true; linkInfo.Text = LinkLabelCode; linkInfo.NavigateUrl = Link; } } * This source code was highlighted with Source Code Highlighter.

По-моему, стало лучше. И не забудем обновить вызовы в коде нашей страницы:

try { if (context == null) context = new PBPWebDatabaseConnection(); if (languageObject != null) { languageObject.LanguageTitle = Server.HtmlEncode(txtLangName.Text); languageObject.LanguageCode = Server.HtmlEncode(txtLangCode.Text); if (filePathToUpload != "") languageObject.IconName = Path.GetFileName(filePathToUpload); if (languageObject.LanguageId == 0) context.AddObject("Language", languageObject); int saved = context.SaveChanges(); if (saved == 1) { panelInfo.ShowOk(Messages.LanguageSaveOK, Messages.LanguagePageToTransfer, Messages.LabelLinkToLanguages, Pages.Languages, 4); Master.AddRedirect(Pages.Languages, 4); panelMain.Visible = false; result = true; } } } catch (Exception ex) { //log } if (!result) panelInfo.ShowFail(Messages.LanguageSaveFail); * This source code was highlighted with Source Code Highlighter.

До идеала, конечно, далеко, но мы постепенно будем улучшать код. Вот такие сообщения у меня получились в итоге:

Пишем CMS. Шаг № 6. Добавление нового языка

2010-03-11T17:20:00.000-08:00

Продолжим.
Сегодня мы добавим функциональность на страницу LanguageEdit.aspx, и сможем добавлять новые языки или редактировать уже существующие.

Для начала определим две переменные: одна будет представлять собой объект Language, который мы создали еще раньше с помощью ADO.NET Framework Entity, а вторая - собственно инструмент работы с БД - контекст:

private Language languageObject; private DatabaseConnection context; * This source code was highlighted with Source Code Highlighter.

Далее в обработчик загрузки страницы Page_Load добавим проверку на наличие id:

if (Request["id"] != null) { int id = 0; int.TryParse(Request["id"], out id); if (id != 0) { try { context = new DatabaseConnection(); var lan = from l in context.Language where l.LanguageId == id select l; languageObject = (Language)lan.First(); } catch { //log } } } if (languageObject == null) { languageObject = new Language(); } if (!IsPostBack) Page.DataBind(); * This source code was highlighted with Source Code Highlighter.

Логика работы этого блока проста: если мы получаем в качестве параметра id, то извлекаем из базы объект по этому id. Если же параметра нет, значит, мы хотим создать новый язык.

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

Теперь разместим на странице наши контролы, для начала это буду два поля ввода - в одном заголовок языка, во втором его кодовое представление (например, "en-EN"), с его помощью удобно сразу выставлять региональные настройки. Позднее мы добавим контрол загрузки файла, с помощью которого будем грузить на сервер иконки с изображением флага, а пока надо разобраться с основными вещами.

Мы подошли к ключевому вопросу - привязка данных к форме. ASP.NET предлагает несколько контролов для привязки данных, но после некоторой возни с ним мне пришлось отказаться от их использования. Фактически, только два контрола - DetailsView и FormView - позволяют отображать данные по одному объекту, но мне так и не удалось заставить их привязываться к EntityObject. По какой-то, неведомой мне причине, эти контролы в качестве источника данных требуют обязательно объект, который наследут IListSource, IEnumerable, или IDataSource. Наш объект EntityObject не реализует ни один из этих интерфейсов. В качестве источника данных можно было бы использовать ObjectDataSource, но для этого нужно соблюсти определенные требования к классам доступа DAL - поскольку мы используем классы, сгенерированные EntityFramework, использование их не получается. Можно, конечно, было бы написать обертку к этим классам, но плодить лишний код не хочется совершенно.

После некоторых раздумий, а также просмотра обновленного кода проекта TheBeerHouse пришлось остановится на простой односторонней привязке данных к объекту. Что это значит? Очень просто - при открытии страницы мы создаем объект, а наши поля, привязанные к нему, заполняются автоматически. Когда мы хотим сохранить измененный объект, мы извлекаем содержимое полей вручную. Полагаю, ручное извлечение неизбежно - ведь объект еще не сохранен, а значит, поля невозможно привязать. Если кто подскажет более удачное решение, будет здорово.

Итак, создаем на странице простое свойство, которое имеет только метод get и возвращает наш объект:

protected Language LanguageObject { get { return languageObject; } } * This source code was highlighted with Source Code Highlighter.

На страницу добавляем текстбоксы и осуществляем привязку, например:

<asp:TextBox ID="txtLangCode" runat="server" Text="<%# LanguageObject.LanguageCode %>" Width="214px" /> * This source code was highlighted with Source Code Highlighter.

А теперь вернемся к первому коду, обратите внимание:

if (!IsPostBack) Page.DataBind(); * This source code was highlighted with Source Code Highlighter.

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

Ну вот, осталось дело за малым: сохранить измененные данные. Кидаем на форму кнопку, добавляем событие Click и в обработчике пишем примерно такой код:

bool result = false; try { if (context == null) context = new PBPWebDatabaseConnection(); if (languageObject != null) { languageObject.LanguageTitle = Server.HtmlEncode(txtLangName.Text); languageObject.LanguageCode = Server.HtmlEncode(txtLangCode.Text); if (filePathToUpload != "") languageObject.IconName = Path.GetFileName(filePathToUpload); if (languageObject.LanguageId == 0) context.AddObject("Language", languageObject); int saved = context.SaveChanges(); if (saved == 1) { panelInfo.Activate(true, Messages.LanguageSaveOK, Messages.LabelLinkToLanguages, Pages.Languages); Master.AddRedirect(Pages.Languages, 4); panelMain.Visible = false; result = true; } } } catch (Exception ex) { //log } if (!result) panelInfo.Activate(false, Messages.LanguageSaveFail, string.Empty, string.Empty); * This source code was highlighted with Source Code Highlighter.

Сначала мы проверяем, не нуль ли контекст. Если вдруг он равен null, создаем новый. Объект languageObject уже должен быть создан к этому времени (пустой или взятый из базы). Перезаписываем его свойства данными из полей формы. Затем, если объект был заново созданный (id у него равно 0), то добавляем в контекст. Если нет, ничего не делаем, потому что в этом случае объект уже привязан к контексту (это произошло, когда мы извлекали объект по id). Осталось просто сохранить объект и отреагировать на полученный результат.

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

Пишем CMS. Шаг № 5. Перенаправляем пользователя

2010-03-10T18:05:00.000-08:00

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

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

<meta http-equiv="Refresh" content="4;url=http://site.com/anotherpage.aspx"> * This source code was highlighted with Source Code Highlighter.

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

Сначала добавим в .cs файл мастер-страницы наш код:

public void AddRedirect(string PageToCode, int SecondsToWait) { HtmlMeta metaRedirect = new HtmlMeta(); metaRedirect.HttpEquiv = "Refresh"; metaRedirect.Content = string.Format("{0};url={1}", SecondsToWait, ResolveUrl(PageToCode)); this.Page.Header.Controls.Add(metaRedirect); } * This source code was highlighted with Source Code Highlighter.

Теперь откроем страницу LanguageEdit.aspx, с помощью которой мы редактируем и добавляем языки. Там мы добавим следующую директиву:

<%@ MasterType VirtualPath="~/Main.Master" %> * This source code was highlighted with Source Code Highlighter.

Эта директива позволяет нам обращаться к мастер странице не просто как к объекту типа System.Web.UI.MasterPage, а к объекту нашего конкретного типа. Если вы запутались, поясняю: когда мы добавляем в проект мастер-страницу, всегда создается класс, который наследует вышеприведенный класс. Однако наша страница имеет объект Master, который всегда определен как MasterPage, и поэтому любые дополнительные члены мастера будут нам недоступны. Мы, конечно, можем осуществлять приведение типа ((Main)Master).OurMethod(), но согласитесь, это не очень красиво. Зато теперь наша страница знает, что мастер не просто MasterPage, а Main, и поэтому мы может осуществлять вызов метода напрямую:

Master.AddRedirect(Pages.Languages, 4); * This source code was highlighted with Source Code Highlighter.

Здесь мы опять же передаем переменную из ресурсного файла, которая имеет значение ~/Languages/Languages.aspx - т.е. страница, которая показывает список всех языков.

Да, не забываем скрывать основную часть формы. Для этого ее (основную часть) можно разместить на панели и просто выставлять ей Visible = false. Не волнуйтесь, что она потащит за собой все данные. ASP.NET, когда видит что что-то невидимое, даже не генерирует html-код.

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

Пишем CMS. Шаг № 4. Показываем пользователю результат действия

2010-03-09T17:41:00.000-08:00

Итак, в прошлом номере нашей программы мы решили, что, как только пользователь что-нибудь такое сделает (добавит, удалит, отредактирует и т.д.) он сначала увидит сообщение (на той же странице по постбэку), а потом результат своего действия (через 3-4 секунды будет перенаправлен на нужную страницу).

Итак, как же сказать пользователю "Все в порядке!"? Первое, что приходит в голову - разместить на странице Label, в методе обработке результата менять цвет и текст в зависимости от результата. Что мне не нравится в этом подходе? Ну допустим мы определяем внешний вид стилями, которые храним в файле CSS, одном на весь сайт. А что, если мы захотим рядом с текстом добавлять картинку или еще как-то украсить его? Будет весьма затруднительно поменять Label на Div на всех страницах, где мы используем сообщения. Поэтому мы так делать не будем. А мы поэтому создадим простой пользовательский контрол. Делается это очень просто:

1. Добавляем новый item в наш проект (предлагаю сначала создать папку Controls и хранить все контролы там), выбираем тип Web User Control.

2. Открываем файл ascx и добавляем такую панель:

<asp:Panel ID="panelInfo" runat="server" Visible="true"> <asp:Label ID="labInfo" runat="server" Text="" CssClass="LabelInfo"></asp:Label> <p></p> <asp:HyperLink ID="linkInfo" runat="server"> <asp:Label ID="labLink" runat="server" Text=""></asp:Label> </asp:HyperLink> </asp:Panel> * This source code was highlighted with Source Code Highlighter.

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

Теперь заглянем в код. У меня это выглядит так:

public void Activate(bool? IsResultOK, string Message, string LinkLabelCode, string Link) { this.Visible = true; if (IsResultOK == null) { panelInfo.CssClass = "PanelInfoFYI"; } if (IsResultOK.Value) { panelInfo.CssClass = "PanelInfoOK"; } else if (!IsResultOK.Value) { panelInfo.CssClass = "PanelInfoFail"; } if (Message != string.Empty) labInfo.Text = Message; if (LinkLabelCode != string.Empty && Link != string.Empty) { linkInfo.Visible = true; string linkText = LinkLabelCode; linkInfo.Text = linkText; labLink.Text = linkText; linkInfo.NavigateUrl = Link; } else linkInfo.Visible = false; } * This source code was highlighted with Source Code Highlighter.

Первый параметр говорит о том, каков результат - если все плохо (false), то подключаем стиль ошибки, если хорошо (true) - положительный результат. Иногда требуется просто проинформировать пользователя, в этом случае передадим null и отобразим сообщение голубеньким.

Теперь посмотрим, как происходит вызов этого метода. После того, как мы положили на форму наш контрол (не забываем о регистрации - <%@ Register src="../Controls/InfoPanel.ascx" tagname="InfoPanel" tagprefix="controls" %> ), мы можем обращаться к нему напрямую:

if (result)
panelInfo.Activate(true, Messages.LanguageSaveOK, Messages.LabelLinkToLanguages, Pages.Languages);

Вот тут немного интереснее. Что это за Messages и Pages? Это имена ресурсных файлов (вернее, классов, которые сгенерировались как только мы добавили файл ресурса). Зачем, спрашивается? Нам нужно, чтобы ссылка отображала текст. Мы, конечно, можем просто захардкодить этот текст, но, во-первых, мы с самого начала договорились, что будем писать красивый код, а во-вторых, и это, конечно, главное, подобный подход может привести к очень большому геморрою в будущем. Представим себе, что мы таким образом захардкодили сообщений эдак... двести по всему проекту... а потом пришла директива сверху: все сообщения начинать со слов "Дорогой пользователь!" И вот мы ползаем по сайту, и, чертыхаясь, исправляем все двести сообщений...

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

Можно, конечно, хранить сообщения в отдельном классе, но по-моему, в ресурсах хранить удобнее. Теперь мы с легкостью можем ссылаться на любые переменные, добавленные в текстовый ресурс, кроме того, студия позволяет сортировать переменные по именам и значениям, что, согласитесь, очень удобно. Значения, которые мы забиваем в табличке ресурсов, можно посмотреть в файле <НазваниеРесурса>.designer.cs

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

Пишем CMS. Шаг № 3. Обработка действий пользователя

2010-03-05T12:50:00.000-08:00

Не волнуйтесь, друзья, все в порядке. Никто ничего не забросил. Шла работа мысли. Оказывается, такие достаточно простые вопросы, как оповещение пользователя и разработка поведения системы в целом вовсе не являются простыми. То есть то, что получилось в результате, конечно, не является биномом Ньютона, однако, как показывает практика, огромное количество сайтостроителей правильный, хотя и простой подход игнорируют начисто. Я имею в виду либо отсутствие таких очевидных вещей, как редирект на нужную страницу, либо отсутствие вообще какой-то информабельности. Интернет-серферы меня поймут - как, бывает, бесит, когда регистрация заканчивается ничем! И непонятно, зарегистрировала тебя система или нет, а если да, то почему ничего не сказала?

Рассмотрим несколько моделей поведения системы.
1. Пользователь нажимает кнопку "Сохранить", система делает Postback и на странице появляется сообщение, что все в порядке. И что потом? Если пользователь нажмет кнопку "Сохранить" или "Отправить", что произойдет? Это зависит от того, что вообще происходит. Вполне может вылететь ошибка, если это, например, удаление, и производится дважды. И вообще, зачем, например, опять показывать пользователю форму с только что введенными данными, если все прошло нормально? Фтопку.

2. Пользователь нажимает кнопку "Сохранить", система благополучно перенаправляет его на список чего-нибудь (где пользователь увидит добавленное). Немного лучше. По крайней мере F5 не будет вызывать ошибку. Минусы этого дела:
- чтобы страница могла определить, какое сообщение показывать, очевидно, надо передавать его через строку запроса, которая будет иметь некрасивый вид;
- гораздо более важно то, что если перенаправление в случае ошибки производится на эту же страницу, пользователь теряет все введенные данные.
Не подходит тоже.

3. Нечно среднее (как сделано в форуме PHPbb). Пользователь видит сообщение об успешной отправке данных 3-4 секунды, после чего система автоматически перенаправляет его на нужную страницу. В случае ошибки пользователь также видит сообщение, перенаправления не происходит, и все данные, введенные пользователем, по-прежнему видны. Если браузер не поддерживает автоматическое перенаправление, пользователь видит на странице, где сообщение, ссылку, и переходит по ней вручную. По-моему, отличный подход.

Вот его мы и будем реализовывать. Рассмотрим сценарий с точки зрения asp.net. Пользователь нажимает кнопку, происходит Postback, мы возвращаемся на ту же страницу, обрабатываем введенные данные. Если все в порядке, показываем сообщение (а саму форму можно спрятать, чтобы не путать пользователя) со ссылкой, примерно 3-4 секунды, после чего перенаправляем пользователя на нужную страницу. Если ошибка, ничего особенного не делаем, просто показываем сообщение. Все данные, введенные пользователем, в результате будут сохранены.

Теперь разобьем задачу на несколько подзадач:
1. Как показывать сообщение и ссылку
2. Как обрабатывать данные
3. Как перенаправить пользователя

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

Пишем CMS. Совет - удаленная отладка

2010-02-18T09:03:00.000-08:00

Иногда бывает так, что кажется - невозможно понять, откуда у ошибки ноги растут. Или как решить данную проблему. В этом случае мне всегда помогает удаленная отладка. "Удаленная" - это не про код и не про машину, а про разработчика. Т.е. разработчик в прямом смысле слова удален от компьютера и кода. Можно пойти в душ, хорошо думается на обратном пути к дому. А главное - ничего не отвлекает. Когда вы сидите за компьютером и мельтешите по коду, замыливаются и глаз, и мозг. Когда код только в уме, это настоящая квинтэссенция мышления. Какое-то там сияние чистого разума. Рекомендую. Во время удаленной отладки надо представить себе вызовы, что почему вызывается и где что может ломаться. То же самое и с программированием - мысленно располагайте проблему перед собой и ищите пути решения. Это даже лучше работает, чем листок бумаги. Серьезно!

Пишем CMS. Шаг № 2. Подключаем ADO.NET Entitry Framework

2010-02-17T18:43:00.000-08:00

Сейчас нам надо разобраться, как работать с Entity Framework. Этот момент довольно подробно описан в моем старом посте здесь, поэтому я не буду повторяться, а лишь опишу шаги и действия, которые надо сделать, чтобы:
1) Сгенерировать классы для работы с БД
2) Просмотреть список доступных языков.
Не так уж много, но для этого шага достаточно.

Итак, создайте в солюшене новый проект, который назовите, например, DAL (data access layer). После создания проекта рекомендуется указать в его свойствах название dll, которая будет сгенерировать и пространство имен, создаваемое по умолчанию. Общепринятой практикой является давать названия в формате <Название производителя>.<Название всего проекта>.<Название конкретного проекта>.

После этого добавьте в проект новый айтем - выберите ADO.NET Entity Data Model. На экране появится визард, в котором вы указываете сервер базы данных (выберите сперва Generate from database), затем укажите таблицы, которые будут использованы для генерирования классов. После этого в вашем проекте появится файлы .edmx и .designer.cs.

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

Теперь в веб-проекте создайте каталог Language и добавьте в него две формы (на основе Master page - это будут Web Content Form). Про мастер-страницу мы поговорим немного позже, а пока, если вы еще не создали ее, то создайте, и добавьте две страницы Languages.aspx и LanguageEdit.aspx. Первая страница позволит нам просматривать список языков и удалять ненужные, вторая - создавать новые и редактировать уже имеющиеся языки.

Откройте страницу Languages.aspx и разместите на ней контрол GridView (на самом деле вы можете разместить любой другой контрол, позволяющий просматривать данные в режиме таблицы, но пусть пока будет этот). Выставьте свойство AutoGenerateColumns = false (нам не нужны столбцы, генерируемые автоматически) и добавьте в таблицу столбцы типа BoundField, для каждого столбца укажите в поле DataField соответствующее поле таблицы. После этого добавьте в референсы проекта референс на наш DAL-проект, затем откройте файл кода Languages.aspx.cs и добавьте в список пространств имен наше пространство имен .DAL.

Создайте метод, например LoadLanguages и добавьте в него простой код, который будет вытягивать все наши языки из базы (пейджинг пока не рассматриваем).

private void LoadLanguages()
{
using (WebDatabaseConnection context = new WebDatabaseConnection())
{
var query = from l in context.Language
select l;
gridLanguages.DataSource = query;
gridLanguages.DataBind();

}
}

Здесь WebDatabaseConnection context - это главный класс для работы с базой данных. Он был сгенерировать Entity Framework и найти его можно в соответствующем файле нашего DAL-проекта. Разумеется, этот код следует обрамить конструкцией try-catch, но мы этого пока делать не будем. Во-первых, потому, что нам надо четко решить, что делать в случае возникновения ошибки, а во-вторых, неплохо бы знать, какое исключение может быть выброшено, чтобы правильно интерпретировать результат. Дело в том, что мы не можем показывать пользователю исходное сообщение, которое будет содержать эксепшн, это противоречит принципам безопасности, да и не нужно особо - ведь уровень подготовки пользователя неизвестен. Поэтому обработкой ошибок мы займемся чуть позже.

Заметьте, что в этом коде мы используем простейшую конструкцию Linq to Entity Framework, чтобы получить все данные из таблицы.

Теперь в код метода PageLoad мы разместим вызов нашего метода, который будет грузить данные в таблицу:

protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
LoadLanguages();
}
}

Здесь мы сначала проверяем, является ли вызов обратным (postback) - это может случиться только в том случае, если мы производим какую-либо обработку данных, поэтому отображать данные нам в этот момент не нужно. Как же так? - спросите вы. А очень просто. Дело в том, что после каждой обработки данных мы будем делать редирект на эту же страницу. Объясню, зачем. Если мы ограничимся одним постбэком и откроем эту же страницу после постбэка без редиректа, а затем нажмем F5, чтобы обновить страницу, браузер покажет сообщение о том, что мы собираемся заново отправить данные. Допустим, мы перед этим удалили язык. У нас будет выбор - отправить данные заново или нажать Cancel. Если мы отменим действие, обновления страницы не произойдет, если нажмем Resend, наше приложение получит повторное сообщение об удалении языка, который уже был благополучно удален, в результате чего мы увидим ошибку. Конечно, можно эту ошибку обработать, но зачем? Куда как проще открыть страницу заново и, сколько мы не будем нажимать F5, повторного удаления (или иного действия) не будет.

Пишем CMS. Шаг № 1. Подготовительная работа

2010-02-12T16:28:00.000-08:00

Прежде всего, определимся со структурой-архитектурой-технологией. Технология - используем связку ASP.NET 3.5 + SQL Server 2005, все это будем делать в бесплатной студии 2008 (то есть конечно, наверное, не всем она досталась бесплатно, но мне лично удалось получить ее на дне разработчика). В процессе разработки надо будет постараться использовать преимущества асп3.5.
Структура сайта проста - есть основной проект, параллельно ему существует админский, а также библиотека для DAL (кто не знает, что это, отсылаю к википедии).

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

1. Настроить систему контроля версий. Как это сделать, очень хорошо описано вот в этой книге: ASP.NET 3.5 Social Networking . Вообще классная книга, рекомендую (шепотом: на этом сайте ее можно скачать; disclaimer: а у меня бумажная, толстая). Можно читать вместо моего блога. Но меня чтение подобных книг неизменно уводит в сторону, я не знаю, почему. Вот еще хорошая книга Разработка Web-приложений в среде ASP.NET 2.0. Задача - проект - решение. Но код в этой книге ужасен. Поэтому рекомендую только для поиска конкретных решений, но ни в коем случае не как пример для подражания.

2. Чтобы вас с самого начала не тошнило от собственного сайта, рекомендую найти ему подходящий шаблон. Его всегда можно будет изменить, а так хоть будем видеть, что где показывать. Огромное количество бесплатных классных шаблонов здесь http://www.oswd.org/. Рекомендую сразу же поменять картинки и цвета, а то, шарясь по интернету, вы с удивлением будете обнаруживать своей собственный сайт, только с другой начинкой. =))

3. Создать БД, таблицы. Для организации локализации нам нужна таблица, в которой мы будем хранить название языка, его код (типа "ru-RU") и название файла иконки.

4. Ну и не забудьте про TDD! Я обычно использую NUnit, очень удобная штука. Для тестов стоит создать отдельный проект. Мне кажется, все знают, как подсоединить NUnit к проекту для тестирования, но если кто-то забыл, спрашивайте.

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

Следующим номером: очень краткий курс по работе с ADO.NET Entity Framework на примере работы с языками.

Пишем CMS или любителям изобретать велосипеды

2010-02-12T15:32:00.000-08:00

Не знаю, как вам, а мне периодически хочется сделать какой-нибудь интересный сайт или сервис. Иногда довожу свою идею до конца, чаще бросаю на середине. Но каждый раз в самом начале встает вопрос - делать с нуля или воспользоваться готовой CMS? Сначала, конечно, я начинаю шарить по интернету в поисках приличной CMS. Ну, я люблю C# и ASP.NET, а не PHP и VB.NET, поэтому список подозреваемых невелик. Но и он очень быстро сужается - почти сразу же выясняется что данная CMS или глючная или очень медленная или какая-то слишком крутая, а мне надо попроще. И, конечно, остается в итоге один вариант - опять писать с нуля. Конечно, мой сайт будет также содержать глюки и тормозить, но это будут мои глюки, которые я постепенно исправлю, и тормоза, наверное, со временем пройдут как-нибудь... сами... Но это ладно, самое-то глупое во всей этой ситуации - писать с нуля один и тот же код. Потому что почти все сайты содержат примерно одинаковую информацию и функционируют по сути совершенно одинаково. Поэтому можно попытаться создать ну не CMS, конечно, это громко сказано, а так... шаблон... фреймворк, ну что-то такое, что можно использовать и потом.
Ну что ж, сказано-сделано.
Во-первых, что за сайт. Сейчас мне нужно сделать один довольно простой сайт, который будет содержать информацию о программном продукте. Возможно, в дальнейшем в него будет добавлено что-то вроде соцсети и магазин. А пока - новости, локализация, фидбэк, страница со скриншотами ну и разное по мелочи. Самое главное - возможность быстро в админке добавлять новости, информацию о продукте, скриншоты, менять иконки флажков для языков, возможность быстро и безболезненно добавить новый язык. Ничего сложного и навороченного, как видите. Можно было бы вообще не писать все это, если бы не одно но. В процессе работы меня периодически осеняет. Ну не то чтобы конечно, в прямом смысле, но все время приходят разные идеи, как можно отрефакторить, как можно сделать удобнее. Меня бесит, например, когда код разметки смешан c JavaScript-кодом, когда переадресация на нужную страницу делается в коде, и стоит потом эту страницу переместить, как переадресация валится, и все в таком же духе. Поэтому я буду свои идеи по ходу дела выкладывать сюда. Если конечно, мне не надоест. А называться это безобразие будет "Пишем CMS. 100 шагов". Я, конечно, не думаю, что приличную CMS можно написать даже за 300 шагов, но, во-первых, 100 звучит красиво и солидно, во-вторых, у меня нет уверенности, что меня хватит даже на 50, в третьих, накрайняк всегда можно поменять первую цифру.
Поехали!

Entity Framework - использование хранимых процедур

2008-08-07T13:44:00.000-07:00

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

Оказалось, очень просто. Ну, во-первых, надо создать саму процедуру. Во-вторых, надо обновить модель - т.е. в ModelBrowser щелкнуть правой кнопкой мыши на модели и выбрать Update Model From Database и там уже выбрать процедуру. После этого она добавляется в модель, но как-то не до конца - в коде она не появится до тех пор, пока вы ей не скажете. А для этого недо щелкнуть на процедуре (в модели) и выбрать Create Function Import. На экране появится окошко, в котором вас спросят, как назвать будущий метод, и что он будет возвращать. После этого можно обращаться к процедуре через контекст, причем обращение как к обычному методу, т.е.

context.Proc(parameters)

Один момент, который следует учесть. Если вы говорите, что процедура возвращает набор записей, которые могут быть приведены к какому-то классу, и если этот класс - полученный из других таблиц, но набор возвращаемых столбцов должен точно соответствовать набору столбцов (членов т.е.) для этого класса. Например, вы говорите, что будущий метод возвращает набор типа Client, а таблица Client в базе содержит три поля: Id, Name, Address. Так вот ваша процедура должна точно возвратить три этих столбца, а если она будет выбирать, например, только два из них, то будут выскакивать ошибки.

MVC - создание и использование повторно используемых компонентов

2008-06-20T12:14:00.002-07:00

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

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

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

public class CategoryController : ComponentController
  {
    public ActionResult Index()
    {
      // Add action logic here
      throw new NotImplementedException();
    }
    public void RenderControl(string CategoryName)
    {
      RenderView(CategoryName);
    }
  }

Т.е. видим два существенных отличия: класс наследует ComponentController, а не просто Controller, и второе - по-другому выглядят методы действия. А выглядят они точно также, как выглядели методы действия обычных контроллеров раньше - т.е. возвращают void и рендерят представление с помощью RenderView.

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

Размещается контроллер вместе с остальными в папке Controllers (думаю, на самом деле эти файлы можно размещать где угодно). А вот с представлением не так все просто. Оно должно лежать в специальной папке Components/[ComponentControllerName]/Views/[ViewName]. Т.е. в корне вы создаете папку Components, в ней произвольную папку, в которой создаете папку Views, а уже сюда кладете файлы представлений.

Дальше все просто. Контроллер компонента создан, представление - тоже, остается только его вызвать. У меня это сделано так: главная страница загружает выпадающий список, в нем на onchange вызывается функция JavaScript, которая с помощью библиотеки Prototype загружает представление с соответствующими параметрами (подробности работы с Prototype смотри в другой записи блога тут). А вот это представление содержит вызов компонента.

Вызов можно осуществлять двумя способами. Во-первых, используя RenderUserControl() - тогда сам вызов будет выглядеть так:

<%= Html.RenderUserControl("~/Views/SomeView.aspx") %>

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

<% =Html.RenderComponent<CategoryController>(c => c.RenderControl("Public")) %>

Здесь мы просто указываем имя представления, а могли бы, например, передавать какой-нибудь идентификатор. Мы можем брать из модели, загруженной в объект ViewData, любой доступный член. Почему бы не передавать его в качестве параметра, например, вот так:

<% =Html.RenderComponent<CategoryController>(c => c.RenderControl(View.Model.PageId)) %>

К сожалению, подобный код не будет работать (из-за бага в MVC). Вы просто увидите ошибку следующего содержания:

Unable to cast object of type 'System.Linq.Expressions.MemberExpression' to type 'System.Linq.Expressions.ConstantExpression'.

Выход нашел некто Chris Sainty (ссылка на его статью в конце заметки). Просто добавляем следующий метод в файл вызывающего представления, и вместо стандартного Html.RenderComnonent вызываем его:

protected string RenderComponent(Expression<Action<CategoryController>> action)
    {
      var controller = new CategoryController();
      controller.Context = this.ViewContext;
      var ex = action.Compile();
      ex.Invoke(controller);
      return controller.RenderedHtml;
    }

Вызов будет выглядеть соответственно:

<% =RenderComponent(c => c.RenderControl(ViewData.Model.ParentCategoryName)) %>

Все работает!

Способ второй. Подтягиваем разметку Html из базы данных
Первый способ, безусловно, хорош. Но у него есть один существенный недостаток - что, если состав вложенных контролов постоянно меняется, т.е. попросту говоря, не является детерменированным? Ничего такого, надо просто каждый раз обновлять версию dll на сервере, и все. Тоже выход, но можно ли обойтись без этого? Можно - например, если хранить код разметки в поле таблицы. Этот вариант подходит для не очень большой и сложной разметки, но зато позволяет обойтись без постоянного деплоя.

Как это сделать? Очень просто - не забываем, что мы можем передать представлению любой класс, а уже в этом классе не составит труда загрузить любое поле из таблицы. Например, так:

private string html;
    public CategoryParameters(int? ParentCategoryId)
    {
      using (DataCoreConnection context = new DataCoreConnection())
      {
        var htm = (from p in context.ItemType
             where p.Id == ParentCategoryId
             select p.ParametersHTML).ToList();
        if (((List<string>)htm).Count > 0)
          html = ((List<string>)htm)[0];
      }
    }
public string Html
    { get { return html;} }

А вот так выглядит вызов:

<%=ViewData.Model.Html %>

Третий способ. Подтягивание представления с помощью Ajax
Подробно о том, как использовать Ajax в проектах MVC, рассказано в другой моей заметке (тут), здесь я лишь покажу, как это использовать в наших целях. Вот код JavaScript, который вызывает представление:

function LoadCategory(parentCategory)
{
  var newDiv = document.createElement("div");
  newDiv.id = "ControlDiv_" + parentCategory;
  newDiv.className = "ControlBlock";
  var url = "Controls/GetCategories/" + parentCategory;
  new Ajax.Updater(newDiv, url,
    {
      method: 'get'
    }
  );
  $('Container').appendChild(newDiv);
}

Т.е. здесь мы динамически создаем блок DIV, в который загружаем содержимое представления, а сам блок помещаем в ранее созданный DIV с Id= Container.

На самой странице же достаточно сделать такой вызов:

<script language="javascript" type="text/javascript">
LoadCategory(1);
</script>

Полезные ссылки:
Статья Chris Sainty, посвященная RenderComponent() и RenderUserControl()
Using the ComponentController in ASP.NET MVC CTP 2 - Mike Bosch

2008-06-20T12:14:00.001-07:00

Вышла третья версия ASP.NET MVC (Preview) - перелопачиваем проект (а лучше создаем новый)

2008-06-06T06:22:00.000-07:00

Значит, вышла, родная. Изменений немерено!
Скачать новую версию можно здесь. Там на странице внизу список доступных файлов. Обязательно скачайте Readme - он содержит перечень всех изменений. А для тех, кто не очень дружит с английским (ну и вообще - для уяснения) перечислю эти изменения здесь.

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

ViewResult - такой тип возвращает метод контроллера View (то, что раньше было RenderView), параметры остаются те же

EmptyResult - ничего не делает - аналогичен тому, что метод действия возвращает null

RedirectResult - перенаправляет на другой URL

RedirectToRouteResult - перенаправление по указанному маршруту

JsonResult - содержимое ViewData сериализуется в формат JSON

ContentResult - рендерит некий текст (обычно это HTML)

Объекты всех этих типов возвращают соответствующие методы контроллера:

View

Redirect - перенаправляет на новый URL

RedirectToAction - перенаправляет на другой метод действия

RedirectToRoute - перенаправляет по новому маршруту

Json - возвращает экземпляр типа JsonResult

Content - рендерит текст (обычно это HTML)

Интересный момент. Если мы пытаемся вернуть объект, не наследующий ActionResult (теоритечески это может быть что угодно), то метод неявно сериализует этот объект в строку (вызывая его ToString()), после чего оборачивает полученный текст в ContentResult и передает его клиенту.

Представления
Теперь ViewData в представлении не заменяется объектом, из которого мы подтягиваем данные. А мы получаем к ним доступ через свойство Model, т.е. вместо ViewData.CitiesForCountry пишем теперь ViewData.Model.CitiesForCountry.

Роутинг
Дефолтные значения теперь задаются проще. Вместо:

routes.Add("route-name", new Route("{locale}/{year}", new MvcRouteHandler()) {
Defaults = new RouteValueDictionary(new {locale="en-US", year=DateTime.Now.Year.ToString()})
}

теперь чуть проще

routes.MapRoute("route-name", "{locale}/{year}", new {locale="en-US", year=DateTime.Now.Year.ToString()});

Это основные новшества. Некоторые моменты касаются констрейнтов, контролов и т.д.

Установка
Поверх не ставится. Сначала надо удалить вторую версию.

Изменения в проекте
Попробуем скомпилировать наш маленький (пока еще) проект. Ну что ж, для начала неплохо - всего 24 ошибки.
Первое, что делаем - удаляем из списка ссылок ссылки на System.Web.Abstractions, System.Web.MVC, System.Web.Routing и заново добавляем их из C:\Program Files\Microsoft ASP.NET\ASP.NET MVC Preview 3\Assemblies. Компилируем опять, уже лучше - всего 14 ошибок.
Далее по тексту файла Readme меняем код. Все компилируется отлично, но одна маленькая проблема - полностью перестает работать роутинг. Т.е. вообще полностью - хотя маршруты и сохраняются в коллекции, однако перехода к методам контролов не осуществляется. Поэтому мне не осталось ничего другого, как создать новый проект, в котором это работает. Мне, к сожалению, так и не удалось найти "5 отличий" между измененным проектом и новым. Если кто-нибудь знает, как это пофиксить, сообщите пожалуйста.
Update Обнаружилась еще одна неприятная фича (которая, конечно, скорее бага). Если у вас модельная часть с edmx находится в отдельном проекте, то из проекта MVC не удалется получить к ней доступ. Т.е. компилируется проект нормально, но при обращении к странице, которая дергает данные из модели, вываливаются непонятные ошибки вроде "включите ссылку на namespace System.Data.Entity". После того, как на страницу импортируешь это пространство имен, начинает кричать, что он не знает, что такое System.Data.Objects. Как только модель была перенесена в проект MVC, подобные ошибки сразу же исчезли. Кто знает, как лечить по-другому, сообщайте.

MVC и Ajax

2008-05-18T13:07:00.000-07:00

Создавая проект на основе MVC, вы можете использовать Ajax, причем сделать это совсем несложно. Кто-то захочет использовать самописный код, а может быть, библиотеку Microsoft Ajax, я же предпочитаю использовать простую и удобную библиотеку Prototype. Единственный видимый ее недостаток - размер (123 К), который устраняется сжатием. Например, можно воспользоваться вот этим онлайновым компрессором, после которого файл уменьшается до 50К, что вполне приемлемо.

Задача
Мне требуется сделать следующую, довольно простую штуку: есть два комбо, в одном перечислены страны, а в другом надо обновлять список городов для данной страны. Т.е. выбрали мы, например, Russia в первом комбо, во втором должны появиться Moscow, SPb и так далее. И естественно, без перезагрузки страницы.

План
Задача на первый взгляд простая и даже тривиальная, и решается она действительно просто. Но давайте в учебных целях подробно рассмотрим план решения.
1. БД - в базе должны были страны и города
2. Entity Framework - интерфейс для доступа к данным.
3. Модель - должен обеспечивать как выдачу списка доступных стран, так и списка городов для страны.
4. Контроллер - должен иметь методы действий для отображения всей страницы (на которой размещаются комбо) и части (обновление второго комбо).
5. Представления - отображение данных.
6. Ajax (prototype) - код для подтягивания данных по событию комбо.

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

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

2. Entity Framework
После создания таблиц надо сгенерировать код для доступа к ним. Можно просто апдейтить нашу модель, но у меня, например, студия сглюкнула и пришлось удалять модель полностью, а затем создавать заново. Чтобы обновить модель, надо перейти в режим Model browser (дважды щелкнуть на файле .edmx - мне такой способ не очень нравится, но другого я не знаю). Затем выбрать корневой элемент в дереве и выполнить команду Update model from database. Далее вы просто выбираете новые таблицы и жмете Finish. Если все пройдет нормально, вы получите обновленную модель и обновленный код доступа к данным.

3. Модель
В каталоге Models проекта создадим два класса - с помощью первого будем извлекать статические данные для первого комбобокса (страны), с помощью второго - динамического для комбо с городами.
Итак, первый класс - StaticData - содержит одно публичное свойство и приватный метод, который забирает из базы список стран.

  public class StaticData
  {
    public List<Country> CountryList
    {
      get
      {
        return GetAllCountries();
      }
    }
    private static List<Country> GetAllCountries()
    {
      List<Country> countries = null;
      using (DataCoreConnection context = new DataCoreConnection())
      {
        countries = (from c in context.Country
               select c).ToList();
      }
      return countries;
    }

  }

Код простейший, добавлю лишь, что DataCoreConnection - это класс типа System.Data.Objects.ObjectContext из файла, сгенерированного при построении модели.
Второй класс аналогичен первому, за исключением конструктора, в который передается код страны:

public class Cities
  {
    private string countryCode;
    public Cities(string CountryCode)
    {
      countryCode = CountryCode;
    }
    public List<City> CitiesForCountry
    {
      get
      {
        return GetCitiesForCountry(countryCode);
      }
    }
    private List<City> GetCitiesForCountry(string CountryCode)
    {
      List<City> list = null;
      using (DataCoreConnection context = new DataCoreConnection())
      {
        list = (from c in context.City
                where c.Country.Code == CountryCode
                select c).ToList();
      }
      return list;
    }
  }

4. Контроллер
Контроллер у нас уже есть - HomeController (поскольку наши комбобоксы располагаются на главной странице). Сюда мы добавим один-единственный метод:

public void UpdateCities(string code)
    {
      Cities cities = new Cities(code);
      RenderView("SelectCity", cities);
    }

Здесь мы всего лишь получаем наши города и передаем экземпляр объекта представлению SelectCity.
Не забываем о роутинге - в файле Global.asax добавим строку:

routes.Add(new Route("Home/UpdateCities/{code}", new RouteValueDictionary(new { controller = "Home", action = "UpdateCities" }),
new MvcRouteHandler()));

Обратите внимание на последний элемент - {code} - это код города, который передается контроллеру. Контроллер принимает его как string code.

5. Представления - отображение данных.
Контролы помещаются на странице (т.е. представлении) Index.aspx. Поскольку страница с момента загрузки должна содержать некоторые статические данные, это должна быть не просто ViewPage, а в нашем случае ViewPage<StaticData>. Сначала отобразим комбобокс со списком доступных стран:

Как видим, мы получаем данные напрямую из ViewData, как будто ViewData - это объект типа StaticData (так оно и есть). Очень удобно. Кого-то может смутить тот факт, что разметка перемешивается с кодом. Как же так? Ведь обещали полное отделение кода! Мммм... ну.... в-общем, ничего страшного. Кода все-таки очень мало, и мне он кажется логическим дополнением к разметке.
Обращаю внимание на объявление обработчика:

onchange="UpdateCitiesList();"

Это функция JavaScript, которая будет подтягивать список городов при изменении значения комбобокса со странами (эту функцию рассмотрим чуть позже).
А пока займемся представлением, обновляющим второй комбобокс. Да-да, комбобокс будет обновлен целым представлением! Добавляем новое представление SelectCity, которое, конечно, объявляем так:

  public partial class SelectCity : ViewPage<Cities>
  {
  }

А вот код, генерирующий содержимое комбобокса:

6. Ajax
Ну а теперь посмотрим, какая функция подтягивает список городов (вернемся к Index.aspx):

1: <script type="text/javascript" language="javascript">
2:   function UpdateCitiesList()
3:   {
4:     if ($('selCountry').value == "0")
5:       return;
6:       var url = '/Home/UpdateCities/' + $('selCountry').value;
7:     new Ajax.Updater('selCities', url,
8:     {
9:       method: 'get'
10:     }
11:         );
12:   }
13: </script>

В строке 4 мы проверяем, не выбран ли нулевой элемент выпадающего списка (тот, который содержит текст "Select ..."). В этом случае просто покидаем функцию. Далее формируем url, к которому будем обращаться - это обычный адрес в MVC, нам надо вызвать контроллер Home, метод UpdateCities, и передать код страны. В строке 7 мы вызываем очень удобный метод Ajax.Updater - он обновляет содержимое нужного нам контрола. Сигнатура метода проста:

new Ajax.Updater(container, url[, options])

Container - это контрол, который требуется обновить; url - вызываемый url; options - мы указали только метод передачи запроса (полный список параметров см. на сайте Prototype).

Как только мы выбираем страну, срабатывает событие onchange выпадающего списка, и Ajax.Updater обновляет комбобокс городов. Все! По-моему, все выглядит просто и красиво.

MVC. Представления

2008-05-17T08:43:00.000-07:00

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

Вообще обычные веб-страницы MVC, т.е. представления являются наследниками класса ViewPagе, а тот, в свою очередь, наследует обычный Page и, кроме того, реализует интерфейс IViewDataContainer. По умолчанию экземпляр ViewPage не включает тэг <form>, поэтому, если вы захотите добавить серверные контролы, не забудьте добавить и форму.
Следует отметить, что представление должно служить только для отображения данных, оно не должно содержать никакой логики или кода доступа к данным. Просто взять данные и отобразить их.

Передача данных
Главное, ради чего создаются веб-страницы (и вообще приложение) - это данные, которые должны быть переданы форме (в нашем случае представлению). В MVC существует несколько способов передать странице данные. Рассмотрим их по порядку.
1. Использование словаря ViewData
Класс Controller содержит член ViewData, он объявлен следующим образом:

public IDictionary<string, object> ViewData { get; }

Как видим, это простая дженерик коллекция, доступ к ней получаем из самого контроллера:

ViewData["CategoryName"] = Category.Name;
ViewData["Categories"] = categories; //categories - это <List>Category

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

Для отображения повторяющихся частей страницы (как в Repeater) можно использовать цикл foreach:

<select>
<%foreach (var cat in ((<List>)ViewData["Categories"]) ){ %>
<option value='<%=cat.id %>'> <%= cat.Name %> </option>
</select>

Обращаю ваше внимание на две вещи:
1. Несмотря на то, что cat имеет "неопределенный" тип var, мы можем обращаться к полям его настоящего типа, поскольку к нему мы привели объект ViewData["Categories"].
2. Мы использовали встроенный код как для содержимого контейнера (для option), так и для определения атрибута тэга (value) - во втором случае кавычки обязательны (даже несмотря на то, что в обычных тэгах мы можем их и не ставить).

2. Использование типизированных объектов
Вы можете создавать слой DAL самостоятельно, я пытаюсь использовать MS EntityFramework, в любом случае у нас есть доступ к типизированным объектам и коллекциям, которые мы прекрасно можем передать странице. Делается это с помощью перегруженного метода RenderView, который в качестве второго параметра принимает любой объект:

protected void RenderView(string viewName, object viewData);

Вот туда-то мы и можем передать, например, список категорий:

RenderView("Category", categories); //categories - это <List>Category

На страницу этот параметр приходит в виде ViewData, поэтому далее мы работаем с ним также, как было показано выше.

Но есть еще более эффективный способ использовать типизированные объекты на странице (уже без всякого приведения). Дело в том, что в MS MVC существует еще один класс, наследующий ViewPage, определенный следующим образом:

public class ViewPage<TViewData> : System.Web.Mvc.ViewPage
Member of System.Web.Mvc

TViewData - это шаблон, вместо него вы подставляете имя класса, содержащего необходимые данные.
Все, что надо сделать - это наследовать представление от ViewPage<TViewData>, например:

public partial class Index : ViewPage<Category>
{
}

После чего прямо на странице можно легко обращаться к ViewData, объекту, который в нашем примере имеет тип Category:

<%=ViewData.Subcategory %>

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

Ссылки по теме:
ScottGu о контроллерах (и представлениях)
ASP.NET Model View Controller Applications > Views and Rendering Helpers

MVC. Контроллеры.

2008-05-15T14:08:00.000-07:00

Итак, добрались мы наконец до самого, на мой взгляд, "вкусного" в этом новом фреймворке - до контроллеров. Это, можно сказать, сердце вашего проекта, построенного на основе MVC. Надо сказать, что концепция контроллеров не кажется сложной, но содержит некоторые нюансы, без знания которых сложно создать что-то стоящее.
1. Как работают контроллеры
Контроллеры - это специальные классы, в которых вы определяете внутреннюю логику работы приложения - откуда взять данные, куда их передать, и какую страницу показать.
Например, если у вас должна быть страница, которая показывает список категорий (чего-нибудь), а также отдельно содержимое категории, то логично создать контроллер Category, в котором определить методы ShowAll и Show, принимающий в качестве параметра id категории.
Подобные методы носят название action methods (методы действия). Вызов метода производится пользователем, когда он кликает ссылку или набирает в адресной строке /Category/Show/5 - показать содержимое категории с id=5. Методы вызываются в соответствии с правилами, определенными в файле Global.asax.

О чем надо помнить. Имя самого класса контроллера должно заканчивать словом controller, а при вызове вы указываете непосредственно имя контроллера, без этого постфикса. Т.е. если вызов /Category/Show/5, то класс контроллера должен называться CategoryСontroller.

Если контроллер содержит публичный метод, который не является методом действия, пометьте его атрибутом [NonActionAttribute].
2. Параметры метода действия
Все параметры, переданные контроллеру, находятся в объекте Request. Кроме значений параметров, оттуда можно извлечь куки и строку запроса. Извлекать параметры очень просто:

int id = Convert.ToInt32(Request["id"]);

Также доступен объект Response. В отличие от стандартных объетов Response и Request ASP.NET (которые являются запечатанными объектами) эти реализуют соответствующие интерфейсы System.Web.IHttpResponse и System.Web.IHttpRequest. Это обстоятельно позволяет создавать псевдообъекты для тестирования контроллеров.
Есть еще более удобный способ извлекать параметры. Для этого метод контроллера должен просто принимать параметр соответствующего типа.

Важно! Не забывайте простую вещь, что именно эти правила определяют роутинг. Если у вас в правилах по дефолту идентификатор передается как id, то в методы вы должны определить параметр точно с таким именем (id, а не CategoryId, например). Если вам нужно передавать именно CategoryId, добавляйте соответствующее правило.

Второй важный момент - тип параметра. Если метод принимает int, а вы передаете ему "hello", возникнет исключение.

Если параметр не совпадает с шаблоном роутинга, или если он вообще не передан, его значение в методе будет null.
Вызывать контроллер можно двумя способами: обычным для MVC (Category/Show/5) и обычным для ASP.NET (Category/Show?id=5).
В конце кода метода действия обычно идет метод RenderView("..."), в качестве параметра указывается имя представления (т.е. страницы, попросту говоря, которая должна быть отображена в браузера при обращении к данному методу).
Кстати, если вызывается метод, которого на самом деле нет, то естественно, возникает ошибка 404. Можно переопределить метод HandleUnknownAction(string actionName) и перенаправить запрос к другому методу действия, используя RedirectToAction (этот метод позволяет вызвать не только другой метод действия в данном контроллере, но и метод любого доступного контроллера).

Ссылки по теме:
ScottGu о контроллерах
ASP.NET Model View Controller Applications > Controllers and Controller Actions

VS 2008 Service Pack 1. Решает одни проблемы и добавляет другие

2008-05-15T13:48:00.000-07:00

Итак, вышли два новеньких сервис-пака, призванные устранить немеренное количество багов и добавить новые. Качать здесь. Прошу учесть, что эти сервис паки - тоже беты, что позволяет их разработчикам выпускать бесчисленное множество последующих версий.
Итак, какие баги, видимые невооруженным глазом, устраняет VS SP1 ?
1. Устранена белиберда с копированием файлов Entity Framework (я имею в виду, что теперь, если ваша модель edmx размещена в одном проекте, а вызываете вы ее в другом, то теперь не надо копировать файлы ssdl, csdl и msl в этот проект). Но копировать строку подключения надо по-прежнему (а то получите сообщение об ошибке Unable to load the specified metadata resource).
2. Устранен дурацкий баг с закрытием файла конфига после его сохранения.
3. Диаграммы EF стали еще красивее... (все изменения EF приведены самими разработчиками в соответствующем блоге).
Больше пока не вспомню.
А вот что появилось:
1. Перестал работать роутинг для страницы Default.aspx. Т.е. если раньше вы спокойно задавали

routes.Add(new Route("Default.aspx", new MvcRouteHandler())
{
Defaults = new RouteValueDictionary(new { controller = "Home", action = "Index", id = "" }),
});

то действительно, после набора в строке localhost:1111/ вы переходили по адресу Home/Index. Теперь браузер упорно зависает на пустой странице default.aspx и ни с места. Пока я эту проблему решаю так: добавляю в default.aspx.cs обработчик Page_Load, где делаю явную переадресацию

Response.Redirect("~/Home");

Топорно, но, по крайней мере, работает.

Разбираемся с ADO.NET Entity Framework

2008-04-27T06:00:00.000-07:00

Итак, в этом проекте мы не будем использовать никаких посторонных систем ORM (про ORM здесь), а попробуем построить слой DAL на основе новой технологии ADO.NET Entity Framework, предложенной Microsoft. Говорят, что это не просто ORM, а нечто большее. Что ж, попробуем понять, что именно. Честно говоря, не совсем понимаю, почему вокруг этой ORM столько шума. Мне, например, очень нравится ORM LLBLGen, я думаю, что эта система ни в чем не уступает майкрософтовской, за исключением, разве что тем, что в ней нельзя использовать LINQ (хотя может быть, и можно).

Entity Data Model
В основе ADO.NET EF лежит модель сущностей, т.е. Entity Data Model. Как и предполагалось, основные объекты модели - это сущности и связи. Все объекты и их связи представлены в виде XML-схемы - в файле с расширением .edmx. Таблицы представлены объектами EntitySet, поля - свойствами Property (обычные поля) и NavigationProperty (поля, участвующие в ассоциациях - ключи, foreign keys).

Служебные объекты (Object Services)
В ADO.NET EF уществует несколько полезных объектов, с помощью которых можно получать доступ к соединению с БД или, например, к выборке из базы, представленной в виде типизированной коллекции.
ObjectContext позволяет получить доступ к соединению, метаданным и еще кое-каким службам.
ObjectQuery - это, по сути, запрос, который возвращает коллекцию типизированных сущностей.
ObjectStateManager кэширует запросы, а также отслеживает изменения в сущностях (с целью дальнейшей синхронизацией с БД).

Mapping
Это то, как полученные сущности связаны с реальными объектами базы данных.

Как все это выглядит
Добавим в наш солюшн еще один проект, который назовем DataCore типа ClassLibrary. Затем в проект добавим новый айтем типа ADO.NET Entity Data model. Сразу же на экране возникает визард, предлагающий нам выбрать, будет ли наша модель построена на основе базы данных, или она будет пустой. Конечно, выбираем Generate from database. Дальше все просто. Визард автоматически подключается к серверу, вернее, сразу к самой базе, после чего мы выбираем таблицы и другие объекты, которые хотим включить в модель. В нашем проекте мы включим следующие таблицы:

aspnet_Applications

aspnet_Membership

aspnet_Users

Category

Comment

Question

UserDetails

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

Если теперь выбрать файл DataModel.edmx в SolutionExplorer, а затем Open with... XML Editor, то мы увидим, как в действительности выглядит этот файл. Это обычный XML, точнее схема, где описаны все элементы: сущности идут здесь как EntitySet, связи между таблицами (ассоциации) как AssociationSet, а отдельные поля - это Properties.

Помимо этой схемы, студия генерирует еще три файла DataModel.csdl, DataModel.msl и DataModel.ssdl. Файл CSDL представляет собой концептуальную схему - это XML файл, в котором представлены объекты на уровне сущностей. Файл SSDL - схема объектов (таблиц и пр.), как они представлены в базе данных.Файл MSL - схема сопоставления - содержит данные о том, как связаны между собой концептуальная схема и схема объектов БД.

Теперь вернемся в Solution Explorer и рассмотрим файл DataModel.Designer.cs. Это самый важный для нас файл, потому что здесь сосредоточены все сгенерированные объекты. Если мы откроем наш первый проект (MVC), то в любом месте сможем, например, написать (не забудьте добавить ссылку на проект):

using (DataCoreConnection context = new DataCoreConnection())
{
Category cat = new FAQEngineModel.Category();
cat.Name = "Web";
context.AddObject("Category",cat);
context.SaveChanges();
}

Итак, что же делает этот код?
В первую очередь он создает объект контекста (DataCoreConnection), который будет уничтожен после выхода за пределы фигурных скобок. Этот объект идет первым в нашем файле DataModel.Designer.cs и является по сути связующим звеном между нашим кодом (объектами) и базой данных. С его помощью выполняются все стандартные операции с данными - выборка, вставка, обновление и удаление.

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

Однако в этом коротком примере кроется одна проблема, которая, как я надеюсь, будет в дальнейшем решена разработчиками студии. Дело в том, что все проходит гладко, когда мы имеем один проект, из которого вызываем наш контекст. Но как только мы выделяем обработку с данными в отдельный проект, а вызываем код из другого проекта, начинаются проблемы. Во-первых, поскольку вызывающий проект (у нас это веб-проект) имеет свой файл конфигурации, в котором содержатся свои строки подключения к БД, он в упор не видит файла конфигурации App.config проекта DataCore, и следовательно, не может подключиться к базе. Как результат, мы видим на экране сообщение EntityConnection error: The specified named connection is either not found in the configuration. Это исправляется легко - достаточно скопировать строку подключения из файла App.config в файл Web.config нашего веб-проекта.

Но тут вылезает другая проблема. Давайте взглянем на строку подключения, которую мы только что скопировали:

Обратите внимание, на какие файлы метаданных она ссылается. Все эти файлы лежат в каталоге bin/Debug проекта DataCore (.\) - т.е. в каталоге, куда помещается dll. Но поскольку мы вызываем эту dll из другого проекта, то получается, что мы ищем эти файлы там, где их нет, и получаем новую ошибку: "The specified metadata path is not valid. A valid path must be either an existing directory, an existing file with extension '.csdl', '.ssdl', or '.msl', or a URI that identifies an embedded resource.". Нам остается два выхода - либо исправить строку подключения ,либо каждый раз копировать нужные файлы в какой-либо каталог веб-проекта.

Попробуем сначала первый способ. Лучше всего, если бы можно было указать относительный путь, например, с использованием какого-нибудь макроса. Единственное, что мне удается найти - это DataDirectory. Но, поскольку мы вызываем файлы из веб-приложения, этот макрос будет заменен каталогом App_Data, который нам вовсе ни к чему. Поэтому можно просто указать абсолютный путь к файлам на диске. Но потом, после деплоймента, эту строку придется менять. Поэтому этот способ мне не нравится.

Второй способ - копирование файлов - тоже не слишком хорош. Получается, что каждый раз, как только я изменяю модель, мне надо куда-то еще копировать сгенерированные файлы? Получается, что так... ладно, пусть это делает за меня студия. Открываем свойства проекта DataCore, идем в Post-Build event и пишем следующее:

copy $(TargetDir)FAQEngineModel.csdl $(SolutionDir)FAQEngine\App_Data\
copy $(TargetDir)FAQEngineModel.msl $(SolutionDir)FAQEngine\App_Data\
copy $(TargetDir)FAQEngineModel.ssdl $(SolutionDir)FAQEngine\App_Data\

Здесь мы просто копируем нужные файлы в каталог App_Data нашего веб-приложения. Теперь остается чуть подправить строку подключения (в файле Web.config):

Все работает!
Решение данной проблемы описано на форуме ADO.NET Entity Framework.

Ссылки по теме:
Обзор ADO.NET Entity Framework
Блог Sergey Rozovik - посты, посвященные EF
Работа с макросами в Pre- и Post-Build events

Microsoft MVC Framework - роутинг

2008-04-12T13:05:00.000-07:00

Правила
В основе роутинга в MS MVC Framework лежит следующий принцип - "мы не обращаемся к файлу, мы обращаемся к классу контроллера, и делаем это через паттерны". Что здесь имеется в виду? А то, что мы действительно не вызываем никакие файлы, т.е. мы пишем в адресной строке не mysite/products/details.aspx?productid=6, а вместо этого указываем "дружественный" URL - mysite/products/details/6. Второй момент - это, конечно, никакой не URL. Т.е. слэши здесь играют роль разделения не папок (как в настоящем URL), а частей (элементов) паттерна. Суть в том, что запрос на сервере разбирается, и каждая его часть (отделенная слэшем) интерпретируется так, как вы задали в паттерне.

Паттерн (или маршрут) это последовательность элементов-заполнителей (placeholders), в соответствие с которыми производится разбор строки запроса. Паттерн может содержать не только некоторые элементы-переменные, но и константные значения. Каждый элемент заключается в фигурные скобки { и }. Элементы отделяются друг от друга слэшем или точкой. Все, что не заключено в фигурные скобки, воспринимается как константа. Типичный пример паттерна:

{controller}/{action}/{id}

А вот строка, соответствующая этому паттерну:

Products/Details/55

Для того, чтобы приложение знало о том, как обрабатывать запрос, паттерн надо зарегистрировать. Лучше всего его регистрировать в событии Application_Start в файле Global.asax. Если вы хотите, чтобы регистрация паттерна была доступна и в проекте, предназначенном для тестирования, то метод регистрации должен быть статическим и принимать в качестве параметра RouteCollection.
Например, регистрация маршрута может выглядеть так:

protected void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}

public static void RegisterRoutes(RouteCollection routes)
{
routes.Add(new Route
(
"Category/{action}/{categoryName}"
, new CategoryRouteHandler()
));
}

Какие запросы могут подходить под этот паттерн? Например, localhost/Category/View/Yachts. А вот запрос localhost/Category/View не подходит, поскольку во-первых, в строке не хватает третьего элемента, а во-вторых, потому, что паттерн не предусматривает дефолтного значения для него (об этом чуть ниже).
Следует учесть, что в процессе регистрации все паттерны складываются в коллекцию, из которой извлекаются в порядке очереди. Это значит, что размещать паттерны надо по степени убывания специализации, как кэтчи в блоке try-catch, и дефолтный паттерн должен идти последним.

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

void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}

public static void RegisterRoutes(RouteCollection routes)
{
routes.Add(new Route
(
"Category/{action}/{categoryName}"
new CategoryRouteHandler()
)
{
Defaults = new RouteValueDictionary
{{"categoryName", "food"}, {"action", "view"}}
}
);
}

Как видим, все достаточно просто - если отсутствует имя категории, подставляем food, если нет action, подставляем view.

Если мы не знаем заранее точно, сколько элементов может содержать строка запроса, но хотим все же как-то обрабатывать запрос, то можно записать паттерн следующим образом:
"Category/{action}/{*titles}" . Звездочка указывает на то, что начиная с этого элемента число последующих элементов может быть любым. Но при этом все они будут трактоваться как третий элемент. Например, для строки запроса localhost/Category/View/Maxi/55 Category - это Category, action - это View, а titles - это Maxi/55. Что делать с таким параметром, мы уже решаем сами.

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

void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}

public static void RegisterRoutes(RouteCollection routes)
{
routes.Add(new Route
(
"{locale}/{year}"
, new ReportRouteHandler()
)
{
Constraints = new RouteValueDictionary
{{"locale", "{a-z}{2}-{A-Z}{2}"},{"year", @"\d{4}"}}
});
}

Мы видим, что элемент year должен содержать 4 цифры, только в этом случае он будет распознан.

Итак, главное, что надо уяснить с роутингом - это то, что строка запроса всегда разбивается ровно на три логические части - controller, action и id. Если вам нужно передать контроллеру (вернее, его методу) параметров больше одного, то вы просто удлиняете запрос, как будто добавляете еще одну папку, а уже в методе разбиваете параметр на нужное количество.

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

Кстати, если при попытке отладки через сервер у вас начнут вылезать странные ошибки вроде Failed to access IIS metabase или Unable to start debugging on the web server. The web server is not configured correctly., просто снесите asp.net 2 и установите его заново - aspnet_regiis.exe -u, потом aspnet_regiis.exe -i .

Да, речь идет только об IIS6. Потому что IIS7 уже умеет работать с приложениями, основанными на MVC Frm, и понимает запросы без расширений файлов, а шестой еще нет. Поэтому надо ему помочь. Для этого надо в код регистрации паттерна включить версию для IIS6. Но для начала в конфиге пропишем явно, на какой версии IIS запускаем наше приложение. Поскольку этот параметр может быть изменен (например, после деплоймента на рабочий сервер), заносим этот момент в наш список TODO. Вот примерный код:

Теперь в код Global.asax добавляем код, с помощью которого сначала производим выбор версии IIS:

protected void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
public static void RegisterRoutes(RouteCollection routes)
{
int iisVersion = Convert.ToInt32(ConfigurationManager.AppSettings["IISVersion"], System.Globalization.CultureInfo.InvariantCulture);

if (iisVersion >= 7)
{
RegisterRoutesForIIS6(routes);
}
else
{
RegisterRoutesForIIS7(routes);
}
}

Затем мы в соответствующих методах регистрируем наши паттерны. Код в методах отличается только наличием расширения .mvc для IIS6. Мне не очень нравится подобное дублирование, но ничего лучше мне придумать не удалось (если придумаете, напишите мне, а я расскажу здесь о вашей идее - с сохранением всех копирайтов, разумеется). Итак, получился примерно такой код:

private static void RegisterRoutesForIIS7(ICollection routes)
{
routes.Add(new Route("{controler}/{action}/{id}", new MvcRouteHandler())
{
Defaults = new RouteValueDictionary(new { controller = "Home", action = "Index", id = "" }),
});
...
}
private static void RegisterRoutesForIIS6(ICollection routes)
{
routes.Add(new Route("{controler}.mvc/{action}/{id}", new MvcRouteHandler())
{
Defaults = new RouteValueDictionary(new { controller = "Home", action = "Index", id = "" }),
});
...
}

Неудобство использования IIS6 проявляется и в том, что нормальные адреса (как предполагалось, без расширений) все равно не получаются. Более того, скажу честно, мне так и не удалось заставить всю эту кухню работать под IIS6. На встроенном в студию сервере - пожалуйста, а под IIS6 - ни в какую. Однако не будем терять надежды. Во-первых, может быть, это всего лишь баг, и его в релизе исправят, а во-вторых, может, к тому времени на серверах отомрут IISы-6...

Хозяйке на заметку

С контроллерами мы будем разбираться позже, сейчас же буквально два слова о том, каким образом MVC Frm узнает о том, что и кому передавать. В основе всего лежит объект System.Web.Routing.UrlRoutingModule, который реализует ничто иное, как интерфейс IHttpModule. Http-модуль характеризуется тем, что вставивается в конвейер обработки запросов. Данный модуль перехватывает запросы и интерпретирует их по-своему. Этот модуль, как полагается, зарегистрирован в файле конфига:

А Http-хандлером является MvcHandler, он решает, какой контроллер вызывать и, соответственно, какой метод. Надо знать, что если в строке запроса указан контроллер, например, Products, то реально сам контроллер (это вообще класс) должен называться ProductController. Имя метода же должно точно соответствовать элементу action запроса.

Полезные ссылки:
Kigg - первый стартер-кит, построенный на MS MVC Framework (клон Digg'a)
Еще кое-что о роутинге

Куда дальше?
В следующей части я рассмотрю архитектуру приложения.

Microsoft MVC Framework - первый взгляд

2008-04-11T12:16:00.000-07:00

Итак, что же это такое - Microsoft MVC Framework ?
Многие (а может быть и все) из нас знают, что совет "разделяй и властвуй" как нельзя лучше подходит к программированию. Веб-программирование проделало долгий путь, постепенно приближаясь к воплощению данного совета в жизнь. Вспомним классический ASP, в котором текст страницы перемежался с кодом, или файлы Perl, в которых, наоборот, код перемежается раздражающими вставками разметки. С появлением ASP.NET и модели "code-behind" кажется, мы приблизились к заветному разделению - код в одном файле, разметка в другом. И все же нет в мире совершенства... лично меня периодически раздражал тот факт, что в коде, обрабатывающем какой-нибудь Postback, надо обращаться к базе (или к слою DAL), и тут же - к элементам интерфейса, и все перемешивается в одну кучу...

Кажется, MVC призвана решить именно эту проблему. Во-первых, что такое MVC? Это такой принцип разработки (он же паттерн), при котором все разделено: интерфейс (View), управление (Controller) и внутренняя логика и данные (Model). Подробнее описано в википедии. Там же, кстати, есть ссылки на более подробные статьи на эту тему.

Microsoft MVC Framework решает данную задачу по-своему, и сейчас мы попробуем разобраться, как именно. В контексте этого фреймворка Model - это некий набор классов, позволяющих манипулировать данными и логикой. Например, это могут быть классы, представляющие некоторые сущности (entities). View - это, естественно, интерфейс - т.е. файл страницы с разметкой. Наконец, Controller - это классы, с помощью которых осуществляется взаимодействие с пользователем, обработка пользовательских данных. Пока не очень понятно, что за всем этим стоит (кроме представления).

Обработка урлов в MVC идет по-особенному, т.е. сервер обращается не к конкретной странице, как это было в ASP.NET, а к классу контроллера, и вот этот-то контроллер и обрабатывает запрос пользователя, а также пользовательский ввод. Кроме того, он, с одной стороны, обращается к модели (т.е. использует логику и данные), с другой стороны, вызывает уже определенный класс представления, т.е., попросту говоря, файл .aspx. С этими процессами связан один интереснейший момент, а именно routing, позволяющий в адресной строке браузера указывать не имена файлов, а путь к некоторому вложенному каталогу (на самом деле это не каталоги, но об этом позже). Т.е. вместо Products/Product.aspx?id=5 мы указываем Products/Details/5. Очень удобно и красиво, а самое главное, просто! Если кто-то пытался сделать подобное в классическом ASP.NET, он сталкивался с невероятными трудностями, о преодолении которых можно почитать в MSDN (URL Rewriting in ASP.NET). Организацию роутинга мы подробно разберем позже, а сейчас продолжим исследование MVC.

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

Полезные ссылки:
дневник ScottGu по теме
Создание веб-приложений без форм
ASP.NET Model View Controller Applications

MVC, Entity Framework и Membership provider. Подготовка.

2008-04-10T07:56:00.000-07:00

Чтобы в дальнейшем работать с пользователями - вход, регистрация, выход, администрирование и т.д. - необходимо использовать какой-то интерфейс. Самым удобным мне кажется Membership provider. Но чтобы заставить работать и его, надо проделать некоторую предварительную работу, о которой я и расскажу.
Всякие установки
Начнем с того, что установим VS 2008, который достался совершенно бесплатно на конференции разработчиков. В пакет также входит SQL Server 2005, а SQL Server Management Studio Express можно также скачать бесплатно.
Теперь надо установить необходимые дополнения - MVC Framework (здесь) и ADO.NET Entity Framework (здесь). После установки при создании нового приложения выбираем Web -> ASP.NET MVC Web Application. Все, студия создала для нас заготовку приложения!
Двигаемся дальше.

База данных
Создаем в студии SQL Server новую базу. После этого в Web.config нашего приложения добавляем строку подсоединения к базе, например:

<add name="Main.ConnectionString" connectionString="Data Source=5D734033\SQLEXPRESS;Initial Catalog=DB;Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient" />

Строку эту, естественно, добавляем в раздел connectionStrings.

Membership
Теперь добавляем настройки для нашего провайдера. Например, такие:

<membership defaultProvider="FProvider" userIsOnlineTimeWindow="1">
<providers>
<clear />
<add name="FProvider"
applicationName="FEngine"
connectionStringName="Main.ConnectionString"
type="System.Web.Security.SqlMembershipProvider"
enablePasswordRetrieval="false"
enablePasswordReset="true"
minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0"
passwordFormat="Hashed"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="true" />
</providers>
</membership>

Далее создаем настройки для провайдера ролей. Например, так:

<roleManager enabled="true"
defaultProvider="rprovider"
cookieName="RC"
cookieTimeout="30"
cookieSlidingExpiration="true"
cookieProtection="All"
cacheRolesInCookie="false"
>
<providers>
<add name="rprovider"
type="System.Web.Security.SqlRoleProvider"
applicationName="FEngine"
connectionStringName="Main.ConnectionString"/>
</providers>
</roleManager>
Все эти настройки нужны для того, чтобы Membership API знал, откуда брать все данные. Если этого не сделать, то он создаст свою собственную базу данных, но нам ведь не это надо, верно?

Заодно не забываем установить authentication mode равным Forms.
Теперь выполним важный шаг, о котором я практически всегда забываю. Надо сгенерировать все необходимые таблицы - для этого находим утилиту aspnet_reqsql.exe и запускаем ее. Эта утилита лежит всегда в одном месте - C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 .
В результате откроется вполне нормальное окошко Windows, где мы сначала нажимаем Next, потом выбираем Configure SQL Server for application services, снова нажимаем Next. Здесь нас просят выбрать сервер базы, тип аутентификации (обычно Windows, особенно на локальном компьютере), имя базы. Сервер у меня определился неправильно, поэтому сначала выскочило сообщение об ошибке. После введение в поля правильного имени в выпадающем списке появились все базы. Выбираем базу, жмем Next, потом опять Next, потом Finish.

Проверим, все ли получилось. Зайдем на сервер, выберем нашу базу данных и посмотрим ее содержимое. Если все в порядке, то в базе должна появиться куча новых таблиц, названия которых начинаются с aspnet_, например, aspnet_Roles.
Вот теперь можно проверить, работает ли наш мембершип провайдер. Для этого возвращаемся в студию, компилируем проект, затем выбираем Project ->ASP.NET Configuration. В результате студия сгенерирует и запустит специальный проект, с помощью которого можно делать некоторые административные вещи, например, устанавливать роли, создавать пользователей. Не думаю, что кто-нибудь пользуется им для реальной работы, но для проверки и установки начальных параметров вполне сойдет.
Итак, после некоторой паузы наконец открывается окно браузера с этим проектом. Внешне все выглядит нормально, но зайдем на вкладку Security. Так и есть! Сообщение об ошибке:

There is a problem with your selected data store. This can be caused by an invalid server name or credentials, or by insufficient permission. It can also be caused by the role manager feature not being enabled. Click the button below to be redirected to a page where you can choose a new data store.

The following message may help in diagnosing the problem: Cannot open database "FEngine" requested by the login. The login failed. Login failed for user 'S-5D7E4033\S'.

Итак, делаю две вещи:
Во-первых, изменяю в свойствах сервера тип аутентификации с Windows на смешанный.
Во-вторых, убираю из строки соединения в файле web.config параметр User Instance=True. Нам это совсем не нужно (насколько я знаю, этот параметр позволяет запускать локальную версию сервера).

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

Идем на вкладку Provider и щелкаем ссылку Select a different provider for each feature (advanced). В результате оказываемся на странице, которая показывает нам отмеченными оба провайдера. Значит, все в порядке.

Идем на вкладку Sequrity и создаем необходимые роли. Я пока вижу только две роли: admin и member. Создаем обе роли, затем пару пользователей - один пусть будет админ, другой - member, т.е. зарегистрированный пользователь.
На этом подготовительную работу можно считать сделанной.

О чем этот блог

2008-04-10T07:51:00.000-07:00

Этот блог посвящен программированию, точнее, одному проекту, который я в данное время и разрабатываю. Проект этот делается на основе достаточно новых технологий - таких, как Microsoft MVC Framework и ADO.NET Entity Framework. По мере разработки я буду писать в блог - описывать очередной этап и проблемы, с ним связанные.
Надеюсь, он (т.е. блог) поможет вам не наступать на те же самые грабли.
Поехали...