Aspect Oriented Programming with SNAP

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

В экосистеме .net cуществует много средств, задача которых предоставлять механизмы логгирования и трассировки. Это могут быть сторонние библиотеки как log4net, NLog. Также остается недооцененным функционал трассировки и логгирования, поставляемый в .net из коробки (NET Framework System.Diagnostics). Есть решения, которые расширяют стандартные средства трассировки .net. В Microsoft Enterprise Library для этих целей есть Logging Application Block, также есть third-party библиотеки, например Essential Diagnostics.

Недостатка в средствах трассировки и логгирования нет. В целом, идея одна и та же, предоставляемый функционал варьируется в ту или иную сторону. Однако, сегодня речь не о выборе logging framework. Более важный вопрос, на мой взгляд, не в выборе той или иной библиотеки, а в ее использовании в нашем приложении, другими словами, как происходят вызовы API библиотеки из нашего кода.

Содержание статьи.

1. Cross-cutting concerns
2. Aspect orientation
3. Классификация AOP framework'ов
4. Выбор AOP framework'а
5. SNAP - Simple .NET Aspect Oriented Programming
   • Реализация аспекта логгирования
   • Применение аспекта
   • Конфигурация аспектов
   • Один метод - много аспектов
   • Недостаток SNAP
   • Keep aspects in container

Behavior Driven Development Explained with MSpec

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

Речь пойдет о behavior driven development, идеях, подходах и используемых инструментах. Слово BDD в последнее время стало своего рода buzzword'ом. Разработчиков можно в целом разделить на тех, кому нравится BDD стиль, и те, кто, относится к нему негативно либо крайне негативно. В статье постараюсь пройти по узкой дорожке и не впасть ни в одну из крайностей. Статья ориентирована на разработчиков, которые интересуются BDD подходом, либо практикуют, либо ищут более оптимальные решения и инструменты.

Рассмотрим следующие вопросы:

1. From unit testing to behavior specifications
   • Goal of unit testing and drawback analysis
   • Executable specifications
   • Given-when-then
   • Scenarios and context/specification style
   • Flavors of BDD approach
2. Использование MSpec - BDD framework in context-specification style
   • Пример спецификации в стиле context/specification
   • Failure verification
   • Simple context
   • Action-common and context-common scenarios
   • Behavior specification suite
   • Behavior/scenario specification style
   • Pros and cons of MSpec
3. Conclusion
   • BDD - идея и реализация
   • Benefits
   • SimpleSpec - simple unit-level BDD framework for .net
   • Resources

NHibernate: mapping class hierarchy

Эта статья погрузит Вас в тонкие материи работы с NHibernate, а именно mapping иерархии классов в смешанном стиле table-per-subclass + table-per-hierarchy + discriminator.

В стиле table-per-subclass, равно как и table-per-hierarchy, нет ничего особенного, это все довольно стандартные и банальные вещи, если речь идет об отображении иерархии классов. Интересное начинается тогда, когда задача выходит за рамки простых учебных примеров, и нужно, например, совместить эти два стиля в рамках отображения одной иерархии классов. Как раз в этих ситуациях и проявляется истинная мощь NHibernate. Об этом мы сегодня и поговорим.

Попутно будет раскрыт ряд интересных моментов, таких как:

• Что такое implicit polymorphism в NHibernate.
• В чем заключается сложность mapping'a интерфейсов.
• [BONUS] Как в NHibernate вытянуть все данные из БД в рамках одного простого запроса.
• Как выглядит sql запрос, который сгенерирует NHibernate для иерархии классов.
• Использование любого sql-выражения в качестве discriminator, а не только фиксированной колонки.

Mapping будет описываться c помощью Fluent NHibernate, также будут даваться ссылки на raw xml-based конструкции.

DI/IoC container lifestyles

В прошлой статье были описаны top-level понятия, охватывающие проблемы управления зависимостями между компонентами в приложении. Были показаны подходы к их решению, в частности при помощи Dependency Injection/Inversion of control контейнеров.

В этой статье будет рассмотрено понятие lifestyle в контексте DI/IoC, описаны существующие типы lifestyle политик на примере Castle.Windsor и Autofac, а также будет показана реализация собственной lifestyle политики для Castle.Windsor.

1. What is lifestyle?
2. Lifestyle types
3. Component tracking and release
4. Lifestyle types comparison in Castle.Windsor and Autofac
5. "Per lifetime scope" lifestyle
6. Implementation of "per lifetime scope" lifestyle for Castle.Windsor

NHibernate session management

Эту статью я хотел бы посвятить работе с NHibernate. Зачастую при обсуждении тех или иных реализаций object-relational mapper'ов много внимания уделяется статическим аспектам их работы, в основном возможностям и реализации O/R mapping'а. Однако, рано или поздно, mapping написан, и нужно перейти к решению поведенческих вопросов, в частности, осуществлению базовых CRUD операций.

В рамках двух статей планирую осветить такие вопросы.

1. Понятие session и transaction scope.
2. Подходы к выбору гранулярности session/transaction и их совместное использование.
3. Дизайн и реализация helper class'ов для облегчения задач управления сессией. Понятие unit of work, применение такой feature NHibernate'а как "contextual session".
4. Реализация паттерна Repository в контексте использования NHibernate.
5. Возможности формирования запросов в NHibernate, и адаптация этих возможностей в реализации Repository паттерна.

Первые три вопроса будут рассмотрены в этом посте.

Mapping object hierarchies with AutoMapper

Сегодня, в процессе работы на текущем проекте, в который раз столкнулся с необходимостью отображать сущности друг на друга. Сущности из domain model отображаются в сущности, принадлежащие data model, а те уже в свою очередь отображаются на базу данных при помощи Entity Framework. Напрямую использовать сущности "made by Entity Framework" не получилось, а так как Entity Framework версии 1.0, и POCO там и не пахло, то возникла такая цепочка отображений: Domain Model <-> Data model <-> Persistent storage.

Однако этот пост не об Entity Framework и POCO, а о применении такой библиотеки, как AutoMapper, в целях облегчения рутинных операций отображения сущностей.

Тестирование поведения приложений: эволюция подходов. От debugging к unit testing, TDD и BDD.

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

В этой статье вспомним что делалось тогда, чтобы убедиться в отсуствии ошибок, чтобы довести программу до работоспособного состояния, в конце концов, чтобы понять что она делает то, для чего задумывалась, и ведет себя корректно. И посмотрим, что делается для этого сейчас, уже когда программирование перестало быть лишь увлечением и переросло в профессиональную разработку ПО. Попытаюсь изложить этапы понимания и развития обеспечения корретного поведения приложений, через которые прошел я. Этапы исключительно субъективны, однако возможно Вы найдете себя в одном из них сейчас или в прошлом.