Вчера первый раз в руках держал свою собственную копию бумажного варианта MSDN журнала. Новость, понятное дело, не эпическая, но хочу сказать, что именно бумажная копия журнала мотивирует на чтение MSDN статей, до этого ни разу я не читал столько статей из одного выпуска. В общем, на одной из первых страниц, в статье A Few of My Favorite Things... in the Entity Framework 4.2 DbContext я увидел следующий код:

var objectContext = (myDbContextInstance as IObjectContextAdapter).ObjectContext

Что плохого в этом коде? Я просто не понимаю смысла использования оператора as в этой строке. Почему бы просто не использовать обычное приведение типов:

var objectContext = ((IObjectContextAdapter)myDbContextInstance).ObjectContext

Чем этот вариант лучше предыдущего? А что если myDbContextInstance все-таки каким-то образом нельзя будет привести к типу интерфейса IObjectContextAdapter? Что будет в этом случае? В первом вариант мы получим всеми нами любимый NullReferenceException, так как оператор as вернет null в случае, если у него не удастся это приведение из типа DbContext в IObjectContextAdapter. Во втором случае мы честно получим тот самый InvalidCastException, который сразу же может дать нам понять, где именно, и в чем ошибка.

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

Сейчас по работе очень активно приходится вспоминать как писать batch скрипты, а так же много работать в command line. Кто писал когда-нибудь скрипты на batch знает, как там все непросто, и как там сильно не хватает многих вещей. Поэтому я решил так же познакомиться немного с Windows PowerShell, так как из этой оболочки уже без проблем можно обращаться к классам .NET, а это уже наше хорошо знакомое поле. Так вот, все знают, что в командной строке cmd можно добраться до предыдущей выполненной команды при помощи клавиши Up, ну и собственно можно просмотреть так историю выполненных команд. Сколько же времени тратится на поиск нужной команды из истории при помощи клавиши Up. А оказывается можно, воспользовавшись клавишами F7/F8/F9, намного быстрее выполнить команду из истории. F7 – самая простая из них просто показывают всю историю в таблице. Увидел я их, при чтении книги по PowerShell, а потом чисто ради любопытства решил попробовать в cmd. В общем, отправляю вас читать документацию на TechNet, если вам тоже приходится много работать с cmd: Windows PowerShell Shortcut Keys (они все работают в cmd).

Зачем, кстати, разработчику использовать Command Line? Ну, чтобы запускать msbuild на нескольких процессорах/ядрах (хотя это конечно можно настроить и в студии), написать скрипты, которые бы очень быстро обновляли тестовую систему…. Да, на самом деле, много для чего… Главное – это попробовать ;)

Термины Behaviors и Interactions ввели две библиотеки, поставляемые вместе с продуктом Expression Blend. Эти библиотеки еще известны со времен Silverlight и WPF, и предполагаю, что большинство разработчиков про них знает. Найти эти библиотеки можно в директории “c:\Program Files (x86)\Microsoft SDKs\Expression\Blend\” (если Windows 32 битный, то без (x86)), если Expression Blend был установлен. В этой папке вы сможете найти  библиотеки для WPF/Silverlight/WindowsPhone. Зачем они нужны и как их правильно использовать вы можете узнать, пройдя по ссылки на MSDN Expression Blend SDK for Windows Phone. Если кратко: это способ расширят функциональность контролов, да еще и так, чтобы поддерживался паттерн MVVM (байндинги и т.п.). 

При разработке своего первого приложения мне потребовалось несколько Behaviors для TextBox, которыми я и хочу с вами поделиться.