Когда не нужен ORM а нужно что-то поменьше. Dapper micro-ORM

Пишем слой доступа к данным? И сразу слышим ответ – Entity Framework или может от бывалого - nHibernate . Программистам подсевшим на ORM в типовых проектах сложно поверить, что есть проекты, которые пишут еще на ADO.NET. Почему? Потому что он быстрый, любая дополнительная прослойка это замедление. Плюс дополнительная библиотека, а если в команде с ней работать умеете только вы, нужно обучать коллег. А если не работаете и вы в том числе, то вы в конечном счете научитесь попутно понаступав на грабли, что обещает вам много ваших вечеров наедине с работой. 

Многие проекты и в том числе новые работают с ADO.NET и по разным причинам. Производительность, полный контроль над запросами и кодом доступа к базе, серьезный и сложный Database back-end c полным фаршем сервисов (Stored procedures, OLAP кубы, Analysis Services и т.д. и т.п.), наличие квалифицированных Database Engineer. Кто-то использует вещи очень специфические для СУБД что нет смысла потом извращать ORM и выполнять через ORM запросы в чистом виде. А для кого-то по большому счету из возможностей, которые дают ORM нужно всего на всего замапить результат запроса из базы на свои объекты. Им не нужна сложность, которые привносят ORM, тратить время на проверку насколько быстро что работает, какие запросы генерятся, как оптимизировать и т.п.

Цепочка обязанностей, chain of responsibilities

Понимание паттернов – это одна из ступеней, следующая – это правильное их применение, причем без перегибов и изменение их под свои нужды когда придется. Про паттерны написано достаточно много. Среди ресурсов откуда можно почерпнуть информацию о них – книги серии Head First Design Patterns вместе с книгой Object-Oriented Analysis and Design из той же серии, или известная книга “банды четырех” Design Patterns: Elements of Reusable Object-Oriented Software, хотя она достаточно сложная при чтении, или вот еще одна, написанная моим коллегой, и простая к пониманию “Дизайн-патерни — просто, як двері”.

Информации достаточно много. Но за последнее время мне chain of responsibilities применялся у меня достаточно часто и позволили неплохо отрефакторить как legacy так и сложный  связанный код. Возможно если поделится типичным сценариями в которых он применился с другими – кому-то это будет полезно. Поэтому я рассмотрю пару сценариев, в которых его применил, и собственно сам базовый код.

Совет: Темная студия :)

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

Недавно вышла новая редакция Visual Studio 2012. Среди прочего добавилась новая опция касательно темы/стиля студии. А именно – возможность выбрать цветовую тему из двух – Light и Dark.

Литература по REST: Книга Pro ASP.NET Web API

Скоро появится новая книжка по темам REST и Web API. Пока она еще только в “альфе” у издательства Apress и готовы всего 3 главы. Но когда ее закончат, будет интересно посмотреть и почитать. Написали ее два MVP: один из Германии (Alexander Zeitler), другой из Турции (Tugberk Ugurlu).

Киевский ITWeekend в сентябре

В Киеве, 15 сентября, я выступал на конференции, которую организовала компания SoftServe, c докладом о REST и Web API. И хотя мне показалось сначала что конференция была более “аджайловой”, так как больше половины всех выступлений было связано с аджайлом, но тем не менее мне понравилось выступать там и общаться с людьми, которые пришли на мой доклад и не только. В общем, было классно, мне понравилось, хоть и у меня лично было мало времени и пришлось относительно рано уехать.

Решил вот выложить свои слайды здесь, чтоб не потерялись. Слайды "под катом".

NDepend 4, меняем SQL на Linq

Я уже писал раньше об NDepend, очень мощной утилите для ревью, аудита и анализа кода. Совсем недавно она обновилась до 4-й версии. В NDepend 4 в основном радуют несколько новшеств:

• Code query and rule over LINQ (CQLinq). Привычный старый SQL подобный язык CQL для написания правил сдвинулся в сторону CQLinq – LINQ подобного или фактически LINQ выражений для написания правил. Старый CQL тоже остался для тех кто с ним сроднился.
• NDepend.API. Дает возможность писать свои собственные статические анализаторы кода базируясь на NDepend.API. Это для тех кому мало CQLinq и собственных правил анализа кода.
• VS 2012 addin support. Поддержка Visual Studio 2012, то есть интеграция NDepend как add-in как это было для предыдущих версий Visual Studio.

REST сервисы и ASP.NET Web API

Самым актуальный способом создать REST сервис в стеке технологий Майкрософт на сегодняшний день является ASP.NET Web API. До того эта технология значилась как WCF Web API и больше по названию тяготела к WCF. Но уже тогда там использовались сходные походы как в ASP.NET MVC, включая роутинг (routing). До нее существовали такие вещи как WCF 4 REST, WCF REST Starter Kit 3.5. Их все еще можно встретить на старых проектах и stackoverflow пестрит вопросами о них. Но то что ASP.NET Web API используется на новых проектах, а некоторые старые конвертируются, чтобы его использовать – радует. Так как предшественники были хуже как в плане технологии (приходилось писать много boilerplating code), удобства использования так и документации.

В предыдущих постах были рассмотрены некоторые теоретические аспекты REST – теперь создадим простой REST сервис с помощью Web API и рассмотрим ключевые элементы такого сервиса.

REST и его Statelessness

Как я уже писал раньше, REST обладает таким свойством как Statelessness или независимости от состояния. Проще говоря, REST не хранит на сервере какое-либо клиентское состояние или сессию. Каждый вызов к REST сервису по одному и тому же адресу URI, и с тем же HTTP Verb по сути обрабатывается одинаково.

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

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

Литература по REST: Книга REST in Practice

В одном из предыдущих постов я попытался описать основные понятия REST понятным языком. Получилось у меня или нет, наврал я там или нет – но одного блог поста для погружения в тему не достаточно. Для хорошего погружения в тему нужно еще знать какие книжки читать и где получить больше информации.

REST

Последнее время много говорят о REST (REpresentational State Transfer). Сейчас эта парадигма с появлением ASP.NET Web API, бывшего WCF Web API, в мире Майкрософт снова станет buzz word, модным буквосочетанием. Конечно появляются все новые вещи, такие как например веб сокеты, которые пересекаются с REST и могут перебрать на себя часть популярности REST. И хотя REST это всего лишь парадигма, говоря об этой парадигме, часто подразумеваются не только идеи, но и набор технологий, с помощью которых эти идеи имплементируются в жизнь. Но тем не менее для правильной и хорошей имплементации этой парадигмы с помощью инструментов, необходимо понимать эти идеи. Они простые, но следование им может служить как документацией, так и помощью, так и сделать дизайн и архитектуру приложения более качественными.