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 помнит то время, с которого началась его, ставшая теперь уже профессиональной, деятельность. Это не отдельный момент времени, а скорее период, когда появилось увлечение компьютерами, информационными технологиями, а затем была первая программа, затем следующая, затем еще и еще. Сейчас сложно даже их назвать программами, хотя тогда они определенны были таковыми.

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

Управление зависимостями между компонентами в приложении

Статья посвящена управлению зависимостями между компонентами в приложении, рассматриваются такие концепции как Dependency Injection, Investion of Control container, Service Locator. Рассматривается существующий подход к управлению зависимостями между компонентами в приложении, анализируются проблемы которые несет в себе этот подход. Далее, путем последовательных шагов делается попытка решить эти проблемы, в результате чего приходим к таким концепциям как Service Locator, Dependency Injection, Inversion of Control Container.

Основной упор в статье делается на вопросы "Зачем?", "Почему?", а не "Как?". Обычно этим вопросам не уделяется должного внимания, и упор делается на детали реализации, однако понимание глубинных причин использования тех или иных вещей критично для их правильного и своевременного употребления.

Статья ориентирована на разработчиков, которые:

  • не слышали об DI/IoC и хотят понять зачем нужно использовать эти новинки, если и "так все хорошо".
  • знают что это такое, но пока не использовали в реальных приложения, и хотели бы более глубже понять необходимость использования DI/IoC, и какие преимущества несет эта концепция.
  • те кто, используют DI/IoC, но хотели бы лучше понять какие проблемы решает DI/IoC и какие benefits несет.

Содержание:

  1. Вопрос управления зависимостями между компонентами в приложении
  2. Классический подход к управлению зависимостями внутри компонент приложения
  3. Использование Service Locator
  4. Использование Dependency Injection / Inversion of control container
  5. Service Locator vs DI/IoC Container
  6. Реализации IoC container'ов
  7. Полезные ресурсы

Приветствие

Доброго времени суток, гости, а возможно и будущие посетители и подписчики моего блога.

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

В основном здесь будут публиковаться посты на технические темы. Будучи по профессии software developer в стеке .NET, посты будут охватывать соответсвующие технологии + темы посвященные разработке ПО в целом. Это будут либо обзоры каких аспектов, либо задачи с которыми я столкнулся и их возможные решения, либо просто мои домашние наброски и эксперименты. Скорее всего в ближайшее время появятся посты посвященные NHibernate или WCF.

В меньшей степени также буду публиковать заметки, не связанные с профессиональной деятельностью, новости моей жизни, заслуживающие всеобщей публикации либо просто какие-то интересности. Так например, в ближайшее время появится статья, посвященная Amazon Kindle e-book reader, его покупке, доставке, и использованию.

В завершение хочу понадеяться, что Вас заинтересуют мои будущие статьи.