Переход на C# 4 и ASP.NET 4.0

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

Причины перехода на новую версию

Причины перехода на новую версию достаточно просты.

1. Язык программирования развивается, в нем появляются новые возможности которые способны значительно упростить нашу жизнь, позволив сконцентрировать усилия на разработке предметной логики.
2. Общий вектор развития системы направлен на привлечение сторонних разработчиков к созданию web-модулей. При этом априори неизвестно кто является этим разработчиком и какие у него запросы. Новая версия среды удовлетворяет наиболее широкий круг запросов.
3. Необходимость поддержки упрощенного способа создания модулей, без тяжеловесного VisualStudio движет нас к адаптации под среду WebMatrix. Сам WebMatrix во многом более заточен под новую среду.

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

Нововведения в языке C#

Все нововведения, представленные в новой версии языка До-Диез (или кому нравится больше - Ре-Бемоль) не имеют под собой каких либо фундаментальных изменений в ядре CLR. Это означает, что по большей части они заключаются в новых простых конструкциях реализующих страые возможности. К таковому явлению в обществе закрепилось именование "Синтаксических сахар".

О наиболее важных кусках синтаксического сахара уже давно написано и даже переведено:

1. http://habrahabr.ru/blogs/net/60206/ - обо всем понемногу
2. http://habrahabr.ru/blogs/net/43773/ - о динамическом вызове методов
3. http://habrahabr.ru/blogs/net/43814/ - о параметрах по умолчанию
4. http://habrahabr.ru/blogs/net/43938/ - о ковариантности обобщений (generic)

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

Динамический вызов мог бы нам пригодиться в системе загрузки модулей, если бы там уже не было все реализовано теми же методами рефлексии на которых этот динамический вызов и работает. Упрощать мы ничего не будем, потому как нам и так все понятно да и возможностей у методов рефлексии гораздо больше. Другой вариант использования, для которого это все и создавалось разработчиками языка - вызов методов из COM-объектов. Теперь не нужно компоненты приводить к какому либо типу. Врочем будте бдительны при использовании ключевого слова dinamic - ошибки могут вылезти в runtime, что для web-приожений не очень-то и хорошо.

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

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

Нововведения в ASP.NET 4.0

Про нововведения в ASP.NET опять же давно и подробно написано. Прошу вас прочитать ASP.NET 4.0 Руководство для разработчиков. Я тоже прочитал этот документик. Страниц конечно много, зато буквы крупные.

Позволю себе прокомментировать написанное в руководстве. Мои комментарии будут следовать ходу повествования в руководстве, за тем лишь исключением, что некоторые, малоинтересные, моменты я буду упускать из виду.

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

Параметры ключевых слов и описания - возможноть прописывать ключевые слова и описание страницы в теге page. Реализация таковой возможности обнажила суть всей системы ASP.NET - средство для разработки на коленке. Тупо ляпнуть 10 aspx-скриптов и здать заказ и получить деньги. Вообще, нормальные разработчики давно уже реализовали свой собственный IminPage и вынесли эту логику туда, не дожидаясь когда за них это сделает Микрософт.

ViewStateMode - третье состояние ViewState - это исключительно правильное нововведение. Очень рекомендую к нему присмотреться повнимательней. Дело в том, что при использовании ViewState, а им пользуются большинство сложных стандартных контролов, он раздувается до неимоверных размеров. Раздутый ViewState сильно увеличивает нагрузку на канал. Хоть для нас это не критично пока, но вот время отклика увеличивается пропорционально размеру ViewState, а время отклика для нас очень критично, У нас оно и так хромает сильно.

Свойство Client IDs - совершенно бесполезная вещь. Не пользуйтесь ею ни в коем случае. Нет никакой проблемы с id тега на клиентской стороне. Просто не надо писать код левой ногой на коленке правой ноги перекинув первую через шею товарища. Как разрабатываются контролы со скриптами я уже описывал в статье "Контрол с клиентским сценарием. Быстрый старт". Изменение поведения генератора ID для клиентской стороны приведет к неотлавливаемым коллизиям в java-скиптах.

Минимизация файла Web.config - безоговорочно хорошо. Не очень только ясно почему мы со 2 и 3 версией среды должны были мучиться.

Расширенное кэширование вывода - очень интересное нововведение. Усматриваю в нем возможность выноса логики кеширования обработаных картинок с различными размерами в отдельное место. Рекомендую присмотреться к этой особенности. Быть может и в картах тоже что-то можно кешировать таким образом. То есть кешировать-то мы и без этого можем во временной папке на сервере где-нибудь. А вот сейчас есть возможность вынести всю эту логику в отдельный класс и сделать её более наглядной, простой  и универсальной.

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

Переадресация навсегда - статусы переадресации - это очень тонкий момент связанный с логикой поисковых систем. Всегда задумывайтесь надо оно вам или нет.

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

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

Новые возможности AJAX - микрософтовский аякс настолько тяжеловесен, что не всякая клиентская сторона без глюков его тянет. То и дело возникают утечки памяти даже в самых простых приложениях. Пожалуйста не ведитесь на заманчивые рассказы о том, как их скрипты сделают за вас всю работу. Тру-вей для нас это локальное общение клиентской стороны с сервером посредством SOAP или, что проще, XML-RPC. Но и здесь не стоит увлекаться и быть аккуратными. Всегда помните о подходе "ненавязчивый джаваскрипт" - система должна оставаться работоспособной даже при выключенных клиентских скриптах.

Интеграция с JQuery - Полная брехня! Написали какую-то приблуду с похожим синтаксисом, для того, чтобы отвлечь разработчиков от популярной библиотеки скриптовой в пользу их "коробочной версии". Всегда помните - Deus ex machine был только у греков, и тех римляне завоевали. А римлянам потом немцы выдали на орехи.

Диаграммы ASP.NET - то что мы уже с успехом использовали при отображении графиков температуры стало частью среды. Поэтому мы в скором времени повыкидываем лишние библиотеки из каталога BIN и упростим конфигурацию еще сильнее.

Улучшение CSS и рендеринг - не используйте сложные и корявые контролы библиотеки классов. Все что нам нужно внутри модуля - это HtmlGenericControl и классы сопутствующие ему. Все стили выносятся в тему. В противном случае управлять системой становится невозможно. Все становится дубовым и ни о какой дизайне уже не может идти речи.

ASP.NET MVC - новая модель разработки web-приложений отличная от Web-Forms. Суть подхода в разделении уровней представления, бизнес-логики и слоя данных. Подход интересный. Необходимо затратить некоторое время на его изучение.