Когда не нужен 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 так и сложный  связанный код. Возможно если поделится типичным сценариями в которых он применился с другими – кому-то это будет полезно. Поэтому я рассмотрю пару сценариев, в которых его применил, и собственно сам базовый код.

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

Принципы GRASP

Про принципы SOLID в сети есть много информации. В каких-то местах – она заумная до ужаса, в каких-то – описано понятным человеческим языком. Почему-то, в последнее время я не могу терпеть слишком заумных объяснений. На поверку дня убеждаюсь, что человек, который действительно знает о чем говорит, всегда может объяснить вещи “человеческим” или более понятным языком, чем принято в кандидатских работах.
Но про принципы GRASP написано немного, а многое из того что написано – отравляет понимание своей заумностью. Конечно вопрос не из простых. Но и сложность тоже не космическая.
Итак, пункт первый – зачем эти принципы?
Объектно-ориентированное программирование (ООП) – я бы сказал, что это набор основных концепций (абстракция, инкапсуляция, наследование, полиморфизм), конструкций (классы, методы) и принципов. ООП – это модель, обобщенная модель части предметной или объектной области для программирования окружающего. Это программирование по обобщенной модели, выражение объектной модели в терминах языка программирования. И модель эта, как и любая другая модель, - осознано ограничена.
Так вот, громадной частью ООП является набор принципов. И тут вроде бы все ясно. Только вот принципов много. И разные авторы выделяют как основные иногда схожие, а иногда и разные принципы, и что удивительно – все правильные.
Моделировать – не сложно. Только проблема в том что мы все таки имеем дело с моделью. А когда объекты (сущности) уже созданы, тогда вступает в игру именно программирование и проектирование. Объекты должны взаимодействовать и при этом модель должна быть гибкой и простой. Вот тут нам и помогают принципы.
GRASP – это набор принципов по версии такого эксперта как Крэг Ларман, который написал о них в своей книге - Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

MapReduce

Что такое MapReduce?

Это подход, алгоритм, ну или паттерн, тут уж как кто назовет, параллельной обработки больших объемов сырых данных, например результатов работы краулеров или логов веб запросов, вообще по статистике до 80% задач могут маппится на MapReduce, и именно MapReduce драйвит NoSQL. Существуют разные имплементации MapReduce. Достаточно известна и запатентована реализация этого алгоритма и подхода Google. Или как пример MySpace Qizmt - MySpace’s Open Source Mapreduce Framework, также используется в Hadoop, MongoDb и еще много разных примеров можно привести. Более детально можно почитать в статье MapReduce: Simplified Data Processing on Large Clusters 

Заменяем строковые константы с именами свойств в коде без рефлексии

Вполне себе практическая задача. В коде много строковых констант с именами свойств (методов, классов…). Хочется избежать таких магических строк, но без использования рефлексии, так как она достаточно медленно отрабатывает.
Самое простое решение – вынести все таки строки в отдельный класс и использовать их только туда.
Но есть еще способ. Это динамически парить такие константы из лямбда выражений. Из преимуществ это дает проверку времени компиляции и более простое переименование, но работает медленнее чем например подход с константами.

Concurrency vs. Parallelism

Если углубляться в тему многопоточности то существует два понятия: Concurrency и Parallelism.
Раньше когда большинство компьютеров содержали одно ядро и одно CPU вопрос в разнице не стоял. Теперь же литература пестрит этими двумя понятиями. Какая же между ними разница?

Версионирование сборок

Я всегда стараюсь привязывать версию билда к дате. Неплохой алгоритм версионирования сборок на заметку. Major и minor версию выставляем в зависимости от своих нужд, Build выставляем как число дней с 1 января 2000 года, а ревизию как число секунд с начала текущего дня.
Например у нас билд версии 4.4, тогда для сегодняшнего дня билд будет 4932, ревизия для времени 14:30:00 – 52200. Итого имеем 4.4.4932.52200. Как по мне неплохо, каждый билд уникальный и сортируется.
Visual Studio так и делает если установить атрибут AssemblyVersion сборки как "4.4.*”. Билд проставляет автоматом как сказано выше, а вот ревизию случайно.