четверг, 9 июля 2009 г.

Скотт Гу о ASP.NET MVC

Когда-то я проезжал Рединг на поезде, и он мне сразу понравился. Вот представился шанс по нему прогуляться. Симпатичный городишко. High streets похожи на Лондон - продаются те же самые кебабы. Но вообще он почище. Есть многоэтажные парковки - в Лондоне я их практически не видел. Одна украшена въющимися растениями, издалека выглядит, как обычный дом.

Мы держали свой путь в TVP (Thames Valley Park). Это типичный американский технопарк, утопающий в зелени, где живут Microsoft, Oracle, ING Direct и ещё много известных компаний. Никак не могли найти TVP Shuttle (автобус), а оказалось, на сайте Microsoft была ошибка в расписании. Хоть автобус и бесплатный, водитель отмечает количество вошедших. Наверное, потом в зависимости от числа перевезенных пассажиров выставляется счет технопарку.

На встречу со Скоттом Гу пришло 230 человек. Он принес с собой два лаптопа сразу! На случай, если один сломается. Вот что значит, профессиональный докладчик. Доклад был прекрасный. Хотя большинство моментов я уже знал (по его же блогу), но всё равно послушал с большим удовольствием. В частности, было интересно послушать о нынешних проблемах, которые будут решены в ASP.NET MVC 4.0.

Но больше всего мне понравилось простое объяснение роли MVC в экосистеме ASP.NET: "Мы не говорим, что WebForms - это мертвое направление. Нет, вы можете использовать их и дальше. Просто MVC дает больше гибкости. Некоторые предпочитают ручную коробку передач, а некоторые - автомат".

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

Скотт не расчитывал, что ему будут задавать так много вопросов. Но всё равно он почти уложился в график - вместо двух часов говорил два часа пятнадцать минут. Потрясающе, как некоторые люди умеют быстро и коротко излагать свои мысли. И ещё удивительно, что, будучи вице-президентом, он по-прежнему умеет работать руками, а не только рисовать красивые графики выполнения проектов.

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

Что делать, если меня не устраивает стандартный route (маршрут) {controller}/{action}/{id}? Я хочу сделать очень красивые URL, например: electronics/computers/laptops/cheap/dell/ . При этом количество уровней переменное. Я вижу три способа:

  • Парсить URL в контроллере, но тогда получается, что я не использую уже готовую функциональность routes.

  • Сгенерировать список всех возможных каталогов (например, их 1000 штук), и загрузить их всех в коллекцию routes. Отдельно взятый маршрут будет выглядить примерно так: electronics/computers/laptops/cheap/dell/ad_{id}.html . Очень удобно, как мне кажется - ничего парсить потом не надо. Но не снизит ли это производительность MVC?

  • Парсить URL прямо в global.asax, используя Routing Rules




Но Скотт предложил четвертый способ, комбинированный: определить в global.asax несколько "основных" маршрутов (например, один для электронники, один для автомобилей и т.д.), а уже конец URL парсить в контроллере. Таким образом, можно будет резко сократить количество маршрутов. В плане красоты кода мне такое решение немного не нравится - получается, логика маршрутизации размазывается по разным местам. Но, наверное, в плане произодительности это действительно лучший способ.

7 комментариев:

г-н Тараканофф комментирует...

Как парсить маршруты в контроллере? Сейчас я пытаюсь реализовать такую логику: получаю все существующие пути маршрутов из БД и динамически создаю маршруты в Global.asax. Насколько это производительно?

г-н Тараканофф комментирует...

Кстати, пасиб за полезный пост.

Valik комментирует...

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

г-н Тараканофф комментирует...

Пробую :) Ваш блог почему-то перестал быть доступным из Казахстанского региона (Казахстан, г. Алматы)... Оставил этот пост через анонимный прокси.

Valik комментирует...

Хм... бывает. Попробуй http://valiki.blogspot.com - вдруг поможет...

Привет Алмате (или как правильно просклонять это слово?) Это родина моей жены. Может, когда-нибудь я там тоже побываю.

г-н Тараканофф комментирует...

В открытом проекте CommunityStarterKit от Микрософта, информация о всех доступных разделах бралась из базы при запуске приложения, затем генерировались пути к разделам и всё это складывалось в кэш контекста (HttpContext). Затем по строке запроса из кэша извлекалась информация о конкретном разделе. В качестве View служил единственный файл default.aspx. По идее, в MVC-проекте можно применить тоже самое - генерировать маршруты при запуске приложения - а контентные страницы генерировать, скажем по pageID - и не задумываться о производительности? Разницы вроде бы как никакой нет...

Или хранить маршруты более накладно, чем информацию о путях и разделах в кэше? Не могу понять ответ Гу... :(

Лондону привет из Алматы! :)

Valik комментирует...

Кто его знает...

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

/russia/population.html
/russia/history.html
/russia/photos.html

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

/russia/{info_type}.html
/ukraine/{info_type}.html

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

А вдруг мы хотим photos.html обрабатывать в PhotosController, а history.html в HistoryController?

Я бы, наверное, для начала брал всё из базы, а проблемы с производительностью решал по мере их появления :)

Ratings by outbrain