Без шума и пыли.

Вышел очередной preview 5 Asp.net Mvc. Для установки необходимо снести старые preview.

• Замечено перемещение Ajax Helper в свое собственное пространство имен.

Насколько я понял, для легкой смены js ajax framework-а.

• IViewEngine немного поменял свою роль и теперь отвечает только за поиск View. 0_O
• Появление Html.RenderPartial

Танцы с IViewEngine стали понятны. Появление RenderPartial и ... и видимо идет движение в сторону subcontroller-ов.

• Added array support for action method parameters.
• Added support for custom model binders(ModelBinder(…)+.).

Насколько я понял теперь с клента в Action можно передавать массивы, а также более сложные типы данных.

• Added a new AcceptVerbs attribute.
• Added a new ActionName attribute.

А вот эти два момента приближают нас к простой full REST реализации ;)

И еще, еще, еще...
Общее впечатление от прочитанного релиза. Framework претерпел некоторый рефакторинг.

Трудности перехода

Судя вот по этой статье, некоторые американские разработчики видели веб-разработку только через призму asp.net. И после выхода asp.net mvc с удивлением для себя заметили, что вокруг мира веб-разработки существует куча других проблем, кроме "как найти подходящий aspnet control для моего сайта/интранет системы". Для человека, всегда работавшего с win-app, трудно понять, что его asp.net приложение не работает, как он хочет, во всех броузерах. Трудно понят, что приложение не хранит состояние между сессиями. Трудно понять почему ему приходится делать работу два раза, clien-side и server-side.

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

Кто-то пришел из мира win-application и увидел родной для себя подход в classic asp.net. Кто-то пришел из мира web-application(perl,php,ruby и так далее и тому подобное).

Я так думаю MS не стало бы возиться с asp.net mvc если бы не видело проблем которые пораждает classic asp.net.

PS. Интересно, сколько человек откликнется на этот пост )

Все когда-нибудь заканчивается

Отпуск тоже когда-то кончается и наступают рабочие будни.

• Отдыхать в городе - это убийство своего отпуска.
• Отдыхать в другом городе - это покушение на убийство.
• Поход по магазинам во время отпуск - это ограбление своего отпуска.
• Отсыпаться во время отпуска - это убийство своего отпуск.
• Поездка на курорт - это гастроли с совершение тяжких телесных повреждений(отравление, ожирение и обгорание)

ТОЛЬКО АКТИВНЫЙ ВИД ОТДЫХА, в любом его проявлении и виде!
Остальное тут

Использование Http Status Code для обработки ошибок

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

Для любого ответа web-сервер генерирует Status Code. Статусы есть наверное на все случаи жизни сервера и request-а.
Классические:
200 OK - все верно обработано
301 Moved permanently - так называемый редирект
403 Forbidden - нет доступа
404 Not Found - нет такого ресурса
Более экстравагантные:
405 Method Not Allowed
411 Length Required
505 HTTP Version Not Supported

Есть еще один статус, который возникает если во время обработки запроса произошла ошибка в коде "500 Internal Server Error".
Как правило пользователь в браузере видет какую-то жуть несусветную и все исключения или ошибку стараются обработать на сервере и выдать в каком-нибудь удобоваримом виде. После такой обработки тот самый "500" статус теряется и теперь сервер возвращает "200 OK".
Далее на клиенте просто выводится текст ошибки, ну или на что фантазии хватит у разработчика.

Большинство браузеров или js-framework умеют работать с 500 статусом. Например при ajax запросе js-frameworks вываливаются в методы(OnError, onFailure). Броузеры имеют свою страничку для отображения ошибок.
Но, после обработки "500" статус пропадает и "клиент" не узнает об ошибке. Приходиться вводит и обрабатывать дополнительную ситуацию на "клиенте", придумывать форматы для информирования об ошибке и так далее.
Зачем городить огород, если клиент и так настроен на обработку "500" кода. Для того, чтобы клиент все правильно понял достаточно после обработки в HEADER опять поместить "500" ошибку.
Для этого можно записать в респонсе(Asp.Net Mvc):

Response.StatusCode = "500";

Теперь клиент правильно поймет, данные относятся к ошибке. А на сервере надо будет правильно эти данные сформировать. Информированием клиента об ошибке займется протокол HTTP.