IObservable<T>

Web application configuration management for different target environments

2012-04-29T21:32:00.000+03:00

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

Содержание:

Классический способ “в лоб” управления конфигурацией.
Где хранить конфигурационные настройки веб приложения для разных окружений?
Лирическое отступление на тему хороших манер при работе с конфигурационными файлами.
Как использовать ASP.NET web.config transformations для генерации конфигурационных файлов для разных окружений (dev, staging, production).
Использование ASP.NET web.config transformations для любого XML файла, а не только для web.config.
Как используя ASP.NET web.config transformations, иметь возможность компилировать приложение на машине без установленного Visual Studio и ASP.NET, а лишь с .NET Framework 4.0.
Пример использования ASP.NET web.config transformation синтаксиса.
Автоматический выбор конфигурационного файла для целевого окружения, и подготовка deployment package посредством собственного скрипта, написанного на Python.

Application target environments

Для типичного веб приложения, о котором сегодня пойдет речь, можно выделить следующие целевые среды развертывания:

local environment
development/QA environment
staging environment
production environment

Есть конечно и более специфичные, но сегодня этих будет достаточно. Local environment можно было бы и не выделять как отдельную полноценную среду, обычно разработчик вручную осуществляет настройку приложения на локальной машине, о деплойменте же как о таковом речи вообще может не идти. IIS application может быть отображен напрямую на папку, где находятся исходники проекта, в web.config по сути находятся настройки для локального окружения. Но если не относится к local environment как к частному случаю, то можно унифицировать процесс развертывания, что есть хорошо.

Configuration places

После того как мы определились с целевыми средами, нужно понять что должно или может меняться в зависимости от среды, а соответственно, что мы хотим конфигурировать. Это могут быть строки подключения к источнику данных, адреса, учетные записи и пароли для внешних сервисов, настройки безопасности, например timeout авторизационного cookie, настройки логгирования, уровень логгирования, получатели лог событий, обработка ошибок и отображение собтвенных страниц с ошибками, настройки сторонних модулей (например, Glimpse).

Web.config and config files good manners

Стандартной практикой является размещение конфигурационных настроек в web.config. Здесь хочется сделать небольшое лирическое отступление, и поговорить о хороших манерах работы с web.config. Мы выносим конфигурационные настройки в web.config или любой другой конфигурационный файл, для того чтобы иметь возможность на лету изменять их без необходимости перекомпиляции всего приложения. Говоря технически, при изменении web.config IIS создает новый AppDomain, загружает туда сборки приложения, и новые запросы обрабатываются уже новой версией приложения в новом AppDomain.

Конфигурационный файл должен содержать только то, что нужно менять в зависимости от окружения (строки подключения), или же то, что меняется часто или на лету в процессе работы приложения (настройки логгирования). Не нужно засорять конфигурационный файл, а тем более XML файл, тем что никогда не будет менятся, или же будет менятся редко. Если что-то меняется редко, реже чем происходит цикл развертывания приложения, то это что-то можно вполне конфигурировать посредством кода и менять в коде, как и любой другой функциональный аспект. Если что-то не меняется никогда, то уносим это что-то в код. Для наглядности можно привести пример с http modules. Если мне не надо включать\отключать некий модуль на лету, то я предпочитаю конфигурировать модуль в коде, а не в конфигурационном файле. Вот как это может выглядеть.

Унифицированная инициализация всех сконфигурированных модулей в Global.asax:

public class MvcApplication : HttpApplication
{
 // ...
 public override void Init()
 {
  base.Init();
  foreach (var httpModule in ServiceLocator.Get<IEnumerable<IHttpModule>>())
  {
   httpModule.Init(this);
  }
 }
 // ...

Регистрация модулей наряду с другими сервисами в контейнере:

protected override void Load(ContainerBuilder builder)
{
 // ...
 builder.RegisterType<ErrorHandlingModule>().AsImplementedInterfaces().SingleInstance();
 builder.RegisterType<RequestLoggingModule>().AsImplementedInterfaces().SingleInstance();
 // ...
} 

public class ErrorHandlingModule : IHttpModule
{
 // ...
}

Если же модулю нужны конфигурационные настройки, то:

public class RequestLoggingModule : IHttpModule
{
 // ...
 public RequestLoggingModule(ILoggingConfig loggingConfig)
 {
  _loggingConfig = loggingConfig;
 }
 // ...
}

Если вы не хотите, чтобы Вас, как разработчиков, постоянно просили исправлять параметры в конфигурационных файлах - делайте конфигурационный файл таковым, чтобы он был интуитивно понятен, понятен не только разработчику, а и другим участникам процесса разработки: QA, release manager, support team. В практической плоскости это может значить не использовать самописные навороченные config sections, а предпочесть словарь ключей <appSettings>. При использовании Castle.DictionaryAdapter в качестве провайдера конфигурационных параметров, это может выглядеть следующим образом.

<appSettings> 
... 
 <add key="Smtp_Host" value="..."/>
 <add key="Smtp_Port" value="..."/>
 <add key="Smtp_UserName" value="..."/>
 <add key="Smtp_Password" value="..."/>
 <add key="Smtp_EnableSsl" value="..."/> 
... 
</appSettings>

Интерфейс для Castle configuration adapter:

public interface ISmtpEmailConfig
{
 [Key("Smtp_Host")]
 string Host { get; set; }
 [Key("Smtp_Port")]
 int Port { get; set; }
 [Key("Smtp_UserName")]
 string UserName { get; set; }
 [Key("Smtp_Password")]
 string Password { get; set; }
 [Key("Smtp_EnableSsl")]
 bool EnableSsl { get; set; }
}

Dependency injection:

public SmtpEmailSender(ISmtpEmailConfig config)
{
 _config = config;
}

Магией инстанциирования прокси класса, и привязки параметров рулит Castle.DictionaryAdapter. Если интересно, то почитать здесь и здесь.

Any.config

Несмотря на то, что web.config’а либо app.config’а вполне хватает для хранения конфигурационных настроек, может возникнуть необходимость завести отдельный конфигурационный файл. Например, NLog.config – для хранения настроек логгирования при использовании NLog. Либо приложение интегрируется с неким legacy компонентом, который конфигурируется исключительно посредством отдельного файла. Либо Вы хотите располагать одним файлом и применять его для разных приложения, таким образом уйти от необходимости поддержки нескольких однотипных файлов.

Classic configuration management

Итак, имеем несколько возможных вариантов хостинга конфигурационных параметров, и необходимость подменять их при развертывании в разные окружения. Рассмотрим способ управления конфигурацией, что называется “в лоб”. Конфигурационные файлы в проекте выглядят следующим образом:

Файлы Web.config и NLog.config содержат конфигурационные параметры актуальные для окружения на локальной машине разработчика, то есть ссылаются на локальные внешние сервисы, содержат учетные записи и пароли локальные для текущего домена, в незашифрованном виде, возможно выключенные настройки безопасности, логгирование на Debug уровне. При деплойменте, создается билд, подготавливается deployment package, загружается на целевой хост, развертывается. Если это в первый раз, то существующие конфигурационные файлы берутся за основу, и необходимые настройки вручную меняются. Если уже есть предыдущая версия приложения, то перезаписывается всё кроме конфигурационных файлов, а содержимое этих файлов мерджится вручную.

Минусы этого подхода очевидны:

Большой объем ручной работы.
Невозможность быстрого развертывания приложения (скажем, до 5 минут).
Необходимость помнить и не перезатереть существующие конфигурационные файлы при развертывании.
Необходимость помнить что является конфигурационным файлом а что нет, и где они находятся. Речь идет о случае, когда кроме web.config у Вас есть еще другие конфигурационные файлы.
Конфигурационные настройки для разных окружений хранятся непонятно где. Возможно, только в самих конфигурационных файлах на целевых хостах, возможно, где-то в заначке у того, кто занимается деплойментом. Если приложение в production окружении случайно перезатерлось вместе с конфигурационными файлами, а заначка пропала, то настройки восстановить будет очень сложно.

Configuration management considerations

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

Keep config settings in version control system

На вопрос что хранить, а что не хранить в системе контроля версия – мой ответ обычно таков: “Хранить все, что относится к проекту”. Конфигурационные настройки, особенно для production окружения, жизненно важны для корректного функционирования приложения. Поэтому у меня нет никаких аргументов в пользу того, чтобы не хранить их в системе контроля версий. Если Вас волнуют вопросы безопасности, то можно зашифровать наиболее критические данные, либо же весь файл.

Duplication vs diff

Если конфигурационные файлы для разных окружений отличаются не сильно, и нужно изменять только несколько параметров, то желательно не дублировать содержимое файлов, а описывать только diff. Например, в Visual Studio 2010 в ASP.NET приложениях есть функция: web.config transformation. Вы можете описать базовый web.config файл, а также файлы с преобразованиями для разных окружений (Web.Debug.config, Web.Release.config).

Web.config files typically include settings that have to be different depending on which environment the application is running in. For example, you might have to change a database connection string or disable debugging when you deploy a Web.config file. For Web application projects, ASP.NET provides tools that automate the process of changing (transforming) Web.config files when they are deployed. For each environment that you want to deploy to, you create a transform file that specifies only the differences between the original Web.config file and the deployed Web.config file for that environment.

Однако, если вы следуете принципу “Хранить в конфиге только тот минимум, который меняется”, то возможно все эти транформации будут излишни для Вас и только добавят головной боли. В таком случае, самый простой вариант – продублировать и поддерживать несколько конфигурационных файлов для разных окружений. В этом случае при добавлении нового параметра, его нужно будет не забыть продублировать во всех файлах. В качестве утешения может служить тот факт, что окружений обычно не так уж и много (development, staging, production).

Если же вы хотите возпользовать функцией трансформации конфигурационных файлов, то стоит учесть, что из коробки она доступна только для ASP.NET приложений, и только если вы пользуетесь “Build Deployment Package” функцией, которую предлагает Visual Studio. Дальше в статье я покажу подход, который позволяет использовать config transformations для любого xml файла, будь то web.config, app.config, любой другой any.config, либо вообще файл, не имеющий отношения к конфигурации.

Automate as much as possible

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

Solution

И так, перейдем к самой интересной части и посмотрим возможное решение на практике. Дано:

Visual Studio 2010, .NET 4.0, ASP.NET MVC.
Два конфигурационных файла: Web.config и NLog.config.
Четыре целевых среды развертывания: local, development, staging, production.

Compilation and configuration transformations

В данном решении, я хочу показать использование web.config transformation возможности за пределами “Build Deployment Package” функции. Изначальное состояние структуры таково.

Удалим файлы Web.Debug.config и Web.Release.config, и добавим Web.dev.build.config, Web.staging.build.config и Web.production.build.config, которые будут содержать трасформации для целевых окружений.

Для того чтобы эти файлы отображались в виде дерева с Web.config в качестве родителя, нужно внести правки вручную в “.csproj” файл проекта.

<Content Include="Web.config">
 <SubType>Designer</SubType>
</Content>
<Content Include="Web.dev.build.config">
 <DependentUpon>Web.config</DependentUpon>
</Content>
<Content Include="Web.staging.build.config">
 <DependentUpon>Web.config</DependentUpon>
</Content>
<Content Include="Web.production.build.config">
 <DependentUpon>Web.config</DependentUpon>
</Content>

По умолчанию в ASP.NET приложении, трансформации, описанные в том или ином файле (Web.Debug.config, Web.Release.config) применяются в зависимости от выбранного Build Configuration (Debug, Release), и результат трансформации перезаписывается в исходный web.config.

Изменим эту схему таким образом, чтобы во время компиляции, отрабатывали все транформации, описанные в наших *.build.config файлах, а в результате создавались новые файлы: *.env.config.

Для этого нам нужно импортировать MSBuild task, который отвечает за трансформацию конфигурационных файлов: “TransformXml”, который описан в сборке “Microsoft.Web.Publishing.Tasks.dll”. Далее, нам нужно вызвать эту задачу указав ей исходный конфигурационный файл, файл с трансформациями, и целевой файл с результатом. Также мы хотим, чтобы эта задача происходила автоматически во время компиляции. Вместо того, чтобы использовать Post-build event, воспользуемся предопределенным MSBuild target: “AfterBuild”. Вот как будет выглядеть “.csproj” файл.

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterBuild">
 <TransformXml Source="$(ProjectDir)\Web.Config" Transform="$(ProjectDir)\Web.dev.build.config" Destination="$(ProjectDir)\Web.dev.env.config" StackTrace="true" />
 <TransformXml Source="$(ProjectDir)\Web.Config" Transform="$(ProjectDir)\Web.staging.build.config" Destination="$(ProjectDir)\Web.staging.env.config" StackTrace="true" />
 <TransformXml Source="$(ProjectDir)\Web.Config" Transform="$(ProjectDir)\Web.production.build.config" Destination="$(ProjectDir)\Web.production.env.config" StackTrace="true" />
</Target>

В результате компиляции получим желаемые файлы в папке проекта.

Проанализируем какие зависимости на внешние сборки имееются:

В первой строке находится import файла: “Microsoft.WebApplication.targets”. Этот import присуствует по умолчанию в проекте типа web application. Путь: “$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications”.
В второй строке находится ссылка на “TransformXml” из сборки “Microsoft.Web.Publishing.Tasks.dll”. Путь: “$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web”.

В обеих случаях пути ссылаются на папку с msbuild дополнениями для Visual Studio 2010. На моей локальной машине это –“C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\”. Это значит, что приложение не будет компилироваться на машине, где не установлена Visual Studio 2010, и возможно ASP.NET. Мы же хотим сделать так, что приложение компилировалось без проблем на любой машине, где есть .NET Framework 4.0.

Первой идеей было скопировать файлы “Microsoft.WebApplication.targets” и “Microsoft.Web.Publishing.Tasks.dll” в некую папку, который находится в репозитории (речь идет о системе контроля версий) наряду с проектом, и также изменить ".csproj" файл, чтобы он ссылался на эти файлы по новому пути.

<Import Project="$(ProjectDir)\..\ms_build_extensions\Microsoft.WebApplication.targets" />
<UsingTask TaskName="TransformXml" AssemblyFile="$(ProjectDir)\..\ms_build_extensions\Microsoft.Web.Publishing.Tasks.dll" />

Папка “ms_build_extensions” могла бы содержать следующие файлы.

Однако на ручное изменение директивы Import в первой строке Visual Studio реагирует предложением о конвертации приложения.

Если продолжить, то в результате исходная Import директива будет воссоздана заново.

В результате, правильным решением будет переопределить переменную “$(MSBuildExtensionsPath32)” следующим образом.

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 <PropertyGroup>
  <!-- ... -->
  <MSBuildExtensionsPath32>..\..\ms_build_extensions</MSBuildExtensionsPath32>
  <!-- ... -->
 </PropertyGroup>

Относительные пути в данном случае работают, а вот применение переменных типа $(ProjectDir) - нет. Внутренняя структура папки “ms_build_extensions” должна в этом случае соотвествовать содержимому папки, которая была задана переменной “$(MSBuildExtensionsPath32)” до переопределения. Из содержимого я оставил лишь нужные мне “$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications” и “$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web”. В целом папка ms_build_extensions занимает 649KB, что позволяет нам хранить ее в системе контроля версий безо всяких колебаний.

Это все что нужно для того, чтобы в результате компиляции на выходе создавались нужные конфигурационные файлы. Если мы хотим, чтобы сгенерированные файлы игнорировались системой контроля версий, то это делается очень легко (на примере .gitignore файла):

# Generated configuration files for different environments
*.env.config

Configuration transformation syntax

В данной статье я не хочу углублятся в синтаксис и содержимое файлов трансформации. Детально со всеми возможностями синтаксиса можно ознакомится здесь.

И все же, в качестве примера рассмотрим преобразование исходного web.config файла, в котором надо изменить значение параметра appSettings, заменить connection string, и включить customErrors mode=”On” для staging окружения. Другие конфигурационные настройки трогать не надо. Исходный web.config файл будет выглядеть следующим образом.

<?xml version="1.0"?>
<configuration>
 <appSettings>
  <add key="myKey" value="myValue"/>
  <add key="Security_SwitchToSecureConnection" value="false"/>
 </appSettings>

 <connectionStrings>
  <add name="myConnectionSettings" connectionString="Data Source=localhost;Initial Catalog=dev_db;Integrated Security=True"/>
 </connectionStrings>

 <system.web>
  <customErrors mode="Off" defaultRedirect="~/Content/static/generic_error.htm">
  </customErrors>

  <sessionState mode="InProc" timeout="10" cookieless="true"></sessionState>
 </system.web>
</configuration>

Файл с преобразованиями “Web.staging.build.config” будет выглядеть следующим образом.

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
 <appSettings>
  <add key="Security_SwitchToSecureConnection" value="true" xdt:Transform="Replace" xdt:Locator="Match(key)"  />
 </appSettings>

 <connectionStrings>
  <add name="myConnectionSettings" 
connectionString="Data Source=stg.host.net;Initial Catalog=stg_db;UserId=myUsername;Password=myPassword" 
xdt:Transform="SetAttributes" 
xdt:Locator="Match(name)"/>
 </connectionStrings>

 <system.web>
  <customErrors mode="On" xdt:Transform="SetAttributes" ></customErrors>    
 </system.web>
</configuration>

В результате после компиляции получим файл “Web.staging.env.config” с примененными преобразованиями.

<?xml version="1.0"?>
<configuration>
 <appSettings>
  <add key="myKey" value="myValue"/>
  <add key="Security_SwitchToSecureConnection" value="true"/>
 </appSettings>

 <connectionStrings>
  <add name="myConnectionSettings" connectionString="Data Source=stg.host.net;Initial Catalog=stg_db;UserId=myUsername;Password=myPassword"/>
 </connectionStrings>

 <system.web>
  <customErrors mode="On" defaultRedirect="~/Content/static/generic_error.htm">
  </customErrors>

  <sessionState mode="InProc" timeout="10" cookieless="true"></sessionState>
 </system.web>
</configuration>

Transformations for Any.config

Ничего не мешает использовать подобные преобразования для любого файла в формате XML. Например файл преобразования для NLog.config файла.

<?xml version="1.0"?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
 <!-- ... -->
</nlog>

Deployment and automatic config file selection

Итак, на выходе имеем для каждого окружения файл преобразований (*.{target_environment}.build.config) и результирующий файл (*.{target_environment}.env.config). Осталось решить задачу выбора необходимого файла в зависимости от целевого окружения и подмены его в качестве обычного (*.config) файла.

В нашем случае всеми задачами развертывания занимается собственный скрипт: подготовка deployment package, копирование на удаленный хост, развертывание на удаленном хосте. Поэтому задача выбора конфигурационных файлов будет одной из задач по подготовке deployment package. Нужно выполнить следующие действия:

В зависимости от целевого {target_environment} определить нужный конфигурационный файл (*.{target_environment}.env.config).
Скопировать его в качетве обычного конфигурационного файла: (*.{target_environment}.env.config) –> (*.config).
Удалить все *.env.config.
Удалить все *.build.config.

Ниже приведен отрывок Python кода, который выполняет эти задачи в рамках deployment скрипта.

config_prefix_for_target_env = "{0}.env.config".format(target_env.environment_name)
config_template_for_target_env = '*.' + config_prefix_for_target_env
print("Apply configuration files for '{0}' environment. Config file pattern is: '{1}'".format(
 target_env.environment_name,
 config_template_for_target_env))
env_config_files = [file for file
 in walkfiles(build_package_path_temp)
 if fnmatch.fnmatch(os.path.basename(file), "*.env.config")]
build_config_files = [file for file
 in walkfiles(build_package_path_temp)
 if fnmatch.fnmatch(os.path.basename(file), "*.build.config")]

# iterate through *.evn.config and apply if config match target environment
# then remove all *.evn.config configs
for file in env_config_files:
 if fnmatch.fnmatch(os.path.basename(file), config_template_for_target_env):
  shutil.copyfile(file, file.replace(config_prefix_for_target_env, 'config'))
 os.remove(file)

# remove all *.build.config
for file in build_config_files:
 os.remove(file)

The end

Сегодня был рассмотрен один из возможных вариантов управления конфигурацией веб приложения для разных окружений. При этом удалось уйти от необходимости ручной конфигурации приложения, внести конфигурационные параметры для разных окружений под управление системы контроля версий, сделать возможным применить ASP.NET web.config transformations для генерации конфигурационных файлов для разных окружений, а также иметь возможность компилировать приложение на машине, на которой установлен лишь .NET framework 4.0, и осуществлять сборку и развертывание автоматически при помощи собственного скрипта.

Tech talk in Grid Dynamics on unit testing, TDD, BDD

2011-12-08T23:35:00.001+02:00

Сегодня выступал с докладом в харьковском офисе компании Grid Dynamics на тему How to build better software with unit testing, TDD, BDD. Иначе говоря, как эти методологии помогают создавать ПО и делать его лучше. Пару слов о содержании презентации и самооценке результатов.

Содержание презентации

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

Презентации, созданные в prezi.com - построены на использовании технологии Flash. И в целом такие презентации выглядят поживее и подинамичней, чем их PowerPoint собратья. Можно создавать неплохие анимационные эффекты, которые могут удачно подчеркнуть идею, например делая zoom in/zoom out при переходе между master/detail слайдами. Главное, не переборщить с поворотами, особенно, если слайды меняются довольно часто - может закружится голова. Короче говоря, лучше один раз увидеть, чем что раз услышать.

Building better software on Prezi

Изначально, идея была рассказать о "Behavior driven development", но по мере создания презентации фокус сместился в сторону unit-тестов и test-driven development.

Важность методик unit-testing, TDD, BDD. Их цель.
Unit testing: why, how, what's in practice?
Понятие test-first development. Шаги к его пониманию.
Test driven development. TDD as a software development process. Как использование TDD улучшает дизайн приложения, как помогает при рефакторинге, как помогает фокусироваться на поведение и другие вопросы?
Пример написания кода в BDD-стиле из проекта MemcacheIt с применением BDD-framework SimpleSpec.

Результаты

Если проанализировать результаты, то я пришел к таким выводам, а именно - что бы я изменил, если бы делал презентацию еще раз.

Сократить время выступления до 20 минут против порядка 40.
Убрать раздел о unit-тестах. Все и так знают, что это такое. Сосредоточиться на TDD и BDD.
Сократить объем теории и показывать больше примеров.
Возможно, показать живой пример создания тестов, написания кода модуля, и запуска тестов в IDE, нежели показывать принт-скрины кода на слайдах.

Как бы там ни было, спасибо ребятам из Grid Dynamics, которые проявили гостепреимство и посвятили почти час своего времени моему докладу. Надеюсь, было интересно.

SimpleSpec - yet another BDD framework

2011-10-30T01:30:00.001+03:00

Сегодня продолжим разговор о Behavior-Driven Development - рассмотрим использование BDD-фреймворка SimpleSpec для описания спецификаций. Статья предполагает у читателя наличие базовых знаний в области Behavior-driven development. В одном из моих прошлых постов описана идея BDD, его отличие от модульного тестирования, существующие фреймворки, такие как MSpec.

Содержание:

Что такое SimpleSpec?
Ключевые идеи и цели
Знакомство с Simple.Spec в scenario-behavior стиле
Behavior-scenario стиль
Behavior-suite стиль
Scenario validation
Сокрытие реализации спецификаций
Выводы

Что такое SimpleSpec?

SimpleSpec is a simple BDD framework for .NET of xSpec type. Specifications are written at a unit level.

SimpleSpec относится к xSpec типу фреймворков, использует given-when-then как язык для описания спецификаций на уровне модулей (unit-level). На данный момент, это тонкая обертка над NUnit, которая используя возможности этого unit-testing фреймворка добавляет семантику BDD, позволяя разработчику описывать спецификации в стиле BDD. Не требует конфигурации, нестандартных unit-test раннеров, внешних зависимостей, инструментов - только NUnit и SimpleSpec. Проект размещен на github.

Да, это еще один BDD-фреймворк, автором которого являюсь Я.
- "Очередной велосипед!?" - скажете Вы?
- Скорее результат моего личного опыта работы с MSpec, осмысление его недостатоков и поиска более простого и лучшего BDD решения.

Ключевые идеи и цели

Простота

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

Сделать так, чтобы реализация BDD в виде фреймворка, не отпугивала разработчиков от самой идеи BDD, как это я часто наблюдаю, когда показываю смесь из статических классов, анонимных делегатов, конструкций =()=> из MSpec. После такой презентации говорить о высоких идеях behavior-driven development уже бесполезно. Фреймворк должен воплощать BDD идеи и быть простым.

Читабельность и документирующая функция

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

Подобная идея разделения не нова, фреймворки типа xBehave (NBehave) так и делают - описание спецификации вынесено в отдельный файл (plain text + custom Domain specific language), а реализация спецификация в другом файле (unit test with C#), и постоянная синхронизация в нагрузку. Такой подход годится для описания спецификаций высокоуровневых пользовательских историй (user stories) в виде приемочных критериев (acceptance criteria), когда обязанности описания и реализации спецификаций разделены между разными ролями (QA, Developer). Однако использование его на уровне модулей (unit-level) привело бы к излишнему усложнению - нужно было бы решать вопросы поиска, синхронизации, реализации собственных DSL.

Чтобы сделать вещи проще и ближе к программистам, спецификации должны быть описаны в одном месте (файл, класс), написаны на одном любимом нами языке, а для разделения описания и реализации должны использоваться конструкции и возможности языка.

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

Поддержка разных стилей описания поведения

Context-specification - это общепринятый стиль описания спецификаций, при котором описывается набор сценариев, каждый из которых содержит набор поведений, которые в наблюдаются в том или ином сценарии. На мой взгляд, сontext-specification - несколько неудачное название, которое не отражает сути. Я предпочитаю называть такой стиль - Scenario-behavior.

Однако не всегда удобно описывать спецификации в модели "cценарий - наблюдаемые поведения". SimpleSpec поддерживает также модель, при которой описывается поведение, которое наблюдается в тех или иных сценариях (Behavior-scenario), либо просто описывается набор поведений без явного выделения сценария (Behavior suite).

Знакомство с Simple.Spec в scenario-behavior стиле

Познакомимся с Simple.Spec на примере спецификации поведения класса, который анализирует посещаемость сайта, в частности для текущего дня позволяет узнать как изменилась посещаемость сайта по отношению к предыдущему дню.

Спецификация с ключевыми моментами выглядит так:

1. This is scenario specification.
Спецификация описана в стиле scenario-behavior (context-specification), то есть двигаемся от сценария к наблюдаемым поведениям. Для этого помечаем класс атрибутом Scenario.Spec.

2. Give a short name to the scenario.
Имя класса используем в качестве краткого описания сценария: when_calculating_visit_count_variation.

3. Use base class for common stuff.
В базовой класс with_site_attendance_analyzer выносим общие вещи, которые повторяются от сценария к сценарию: вспомогательные методы, создание нужных объектов. Однако надо соблюдать баланс между желанием вынести все общее за скобки и самодостаточностью спецификации. В идеале, спецификация не должна быть перегружена повторяющимися деталями и реализацией, но в тоже время для понимания спецификации должно быть достаточно взглянуть на один класс спецификации, без необходимости перемещаться между классами. Некоторые разработчики очень любят строить глубокую иерархию, однако я бы рекомендовал использование максимум одного уровня иерархии. Большее количество уровней излишне усложнит поддержку спецификаций.

4. Give a detailed description of the scenario in constructor.
Подробно описываем сценарий в конструкторе. Описание сценария состоит из задания контекста (given) и вызова действия (when).

5. Setup context using givens.
Используем одну или больше конструкций Given(...) для задания контекста.

6. Custom Domain specific language using methods and delegates.
Обычно задание контекста - это именно то, что чаще всего повторяется от сценария к сценарию. Здесь имеет смысл смоделироть логику создания контекста в виде методов, переместить их в базовый класс и вызывать их с нужными параметрами. attendance_statistics_analyzer(...) - создает объект SiteAttendanceAnalyzer, собственно это то, что мы тестируем, и его зависимости. attendance_statistics(...) - задает данные о статистике посещения сайта. Подобный подход позволяет нам убить трех зайцев: выделить повторяющиеся вещи в базовый класс и разгрузить спецификации, разделить описание спецификации и ее реализацию, создать собственный Domain specific language для описания конкретного сценария.

7. Specify action using when.
Используем контрукцию When(...) для описания действия. Сценарий может содержать только одну конструкцию When. Если посмотреть на код, то здесь мы используем анонимный делегат. Было бы излишним усложнением для одной строчки кода создавать отдельный метод. Более того, вызов метода analyzer.CalculateVisitVariation(...) и так говорит сам за себя.

8. Specify one or more observable behaviors.
После того как сценарий описан, описываем наблюдаемые поведения. Для того чтобы пометить поведение, используется атрибут Behavior. Несколько поведений в сценарии - это вполне валидная ситуация, более того в context-specification стиле это даже поощряется, так что не нужно ограничивать себя одним поведением на сценарий. В данном стиле cценарий - это то, что является первичным, и то, от чего следует отталкиваться.

9. Do not use NUnit assertions. To be completely BDD'y use shoulds.
Так или иначе, спецификация должна содержать фазу проверки. Вполне можно использовать механизмы Assert.That, которые есть в NUnit, но я бы рекомендовал использовать любую библиотеку для проверок в BDD стиле, которая предлагает конструкции типа Should(...) (Fluent.Assertions, NUnit.Should, и др.).

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

Описание спецификации отделено от реализации. Все детали реализации и тестирования вынесены в методы.
Для структурирования спецификаций используется язык given-when-then, а также применяется собственный DSL, засчет именования методов.
Ориентированность на поведение, а не на API-модуля. Так или иначе, вызовы API модуля никуда не делись, но они являются деталями реализации и не интересуют нас в первую очередь, а поэтому скрыты.

Behavior-scenario стиль

Подход scenario-behavior, описанный выше применим в большинстве случаев. Однако не всегда. Допустим, в примере с анализом посещаемости сайта нужно провалидировать данные о посещаемости. Бизнес-требования таковы, что данные о посещаемости будут считаться невалидными, если изменение посещаемости превышает заданный порог или если нет данных по некоторым дням. Если исходить из стиля scenario-behavior, то для каждого "если" нужно создать класс и описать сценарий. В каждом таком сценарии мы хотим проверить, что валидация либо пройдет успешно либо не пройдет. В таком случае более проще и компактней будет сначала описать поведение, и лишь потом перейти к списку сценариев, в которых это поведение наблюдается.

[Behavior.Spec]
public class attendance_data_should_not_pass_validation : with_site_attendance_analyzer
{
    public attendance_data_should_not_pass_validation()
    {
        Given(attendance_statistics_analyzer);
        CouldFailWith<ValidationException>().Verify(ShouldFail);
    }

    [Scenario]
    public void when_visit_variation_threshold_is_exceeded()
    {
        Given(() => attendance_statistics(
            new AttendanceSummary(new DateTime(2011, 7, 1), 10, TimeSpan.FromMinutes(1), 2, 13),
            new AttendanceSummary(new DateTime(2011, 7, 2), 15, TimeSpan.FromMinutes(2), 3, 15),
            new AttendanceSummary(new DateTime(2011, 7, 3), 16, TimeSpan.FromMinutes(3), 4, 16)));
        Given(() => analyzer.LoadClientStatistics(resource, new DateTime(2011, 1, 1), new DateTime(2012, 1, 1)));
        When(() => analyzer.Validate(0.4));
    }

    [Scenario]
    public void when_statistics_is_not_contiguous_with_some_days_missing()
    {
        Given(() => attendance_statistics(
            new AttendanceSummary(new DateTime(2011, 7, 1), 10, TimeSpan.FromMinutes(1), 2, 13),
            new AttendanceSummary(new DateTime(2011, 7, 3), 11, TimeSpan.FromMinutes(2), 3, 15),
            new AttendanceSummary(new DateTime(2011, 7, 4), 12, TimeSpan.FromMinutes(3), 4, 16)));
        Given(() => analyzer.LoadClientStatistics(resource, new DateTime(2011, 1, 1), new DateTime(2012, 1, 1)));
        When(() => analyzer.Validate(0.4));
    }
}

Подход behavior-scenario противоположен подходу scenario-behavior. Имя класса отражает поведение. Класс помечен атрибутом Behavior.Spec. В конструкторе задается контекст, общий для всех сценариев, хотя в данном случае это необязательно и сделано, чтобы разгрузить последующее описание сценариев от повторяющихся элементов, которые не добавляют смысла. Ключевой момент - это описание поведения один раз в конструкторе. Далее описываются сценарии, в которых наблюдается данное поведение, соотвествующие методы помечаются атрибутом Scenario. Сценарий, как и прежде, состоит из задания контекста (given) и выполнения действия (when).

Вот как выглядит результаты выполнения спецификации:

Стиль behavior-specification стоит использовать только тогда, когда есть фиксированный малый набор поведений, которые проявляются в большом количестве сценариев. Иначе, стоит придерживаться scenario-behavior стиля.

Behavior-suite стиль

Еще один стиль описания спецификаций - это простой плоский список поведений (behavior suite). Его стоит применять тогда, когда отдельное выделение сценария приведет к излишнему усложнению, либо когда количество сценариев и поведений приблизительно одинаково и все поведения уникальны, либо когда все слишком просто, чтобы заморачиваться со сценариями. Есть плоский список поведений, в котором каждое поведение - это неразрывная связка сценария и собственно поведения.

[Behavior.Spec]
public class device_collection_behaviors
    : specification
{
    private DeviceCollection Devices;
    private Device A1Device = new Device(1, "A1", "A", "X", null);
    private Device A1DuplicateDevice = new Device(1, "A1", "A", "Z", null);
    private Device A2Device = new Device(1, "A2", "A", "Y", null);
    private Device B1Device = new Device(1, "B1", "B", "X", null);

    public device_collection_behaviors()
    {
        Given(() => Devices = new DeviceCollection(new[]
        {
            A1Device,
            A1DuplicateDevice,
            A2Device, 
            B1Device
        }));
    }

    [Behavior]
    public void should_get_devices_by_name()
    {
        Devices.GetByName("A1").Should().BeEquivalentTo(A1Device, A1DuplicateDevice);
        Devices.GetByName("B1").Should().BeEquivalentTo(B1Device);
        Devices.GetByName("C").Should().BeEmpty();
    }

    [Behavior]
    public void should_get_devices_by_type()
    {
        Devices.GetByType("A").Should().BeEquivalentTo(A1Device, A1DuplicateDevice, A2Device);
        Devices.GetByName("B").Should().BeEquivalentTo(B1Device);
        Devices.GetByName("C").Should().BeEmpty();
    }

    [Behavior]
    public void should_get_devices_by_supplier_name()
    {
        Devices.GetBySupplierName("X").Should().BeEquivalentTo(A1Device, B1Device);
        Devices.GetBySupplierName("Y").Should().BeEquivalentTo(A2Device);
        Devices.GetBySupplierName("C").Should().BeEmpty();
    }
}

В примере выше описывается поведение класса-коллекции устройств - DeviceCollection. В конструкторе задан общий контекст. В методах, помеченных атрибутом Behavior, совмещен вызов API модуля и проверка результатов. По внешнему виду, этот подход больше напоминает классические юнит тесты.

Scenario validation

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

Рассмотрим такой сценарий: подсчет изменения посещаемости сайта по отношению к предыдущему дню для первого дня собранной статистики. Очевидно, подсчитывать изменение статистики для первого дня не имеет смысла, поэтому такой сценарий считается невалидным.

[Scenario.Spec]
public class when_calculating_visit_count_variation_for_a_day_with_no_attendance_data 
    : with_site_attendance_analyzer
{
    public when_calculating_visit_count_variation_for_a_day_with_no_attendance_data()
    {
        Given(attendance_statistics_analyzer);
        Given(() => attendance_statistics(
            new AttendanceSummary(new DateTime(2011, 6, 1), 4, TimeSpan.FromMinutes(1), 2, 12),
            new AttendanceSummary(new DateTime(2011, 6, 3), 8, TimeSpan.FromMinutes(2), 10, 123),
            new AttendanceSummary(new DateTime(2011, 6, 4), 5, TimeSpan.FromSeconds(50), 4, 6)));
        Given(() => analyzer.LoadClientStatistics(resource, new DateTime(2011, 6, 1), new DateTime(2011, 6, 3)));
        When(() => analyzer.CalculateVisitVariation(new DateTime(2011, 6, 2)));
        CouldFailWith<ArgumentException>();
    }

Подобно примеру ранее, в конструкторе класса описан сценарий. Обратите внимание на строчку.

        CouldFailWith<ArgumentException>();

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

А далее два пути: либо проверка на корректность, либо на некорректность.

    [Behavior]
    public void should_fail()
    {
        Then(() => ShouldFail("does not have attendance statistiscs"));
    }

    [Behavior]
    public void should_not_fail()
    {
        Then(() => ShouldNotFail());
    }

Сокрытие реализации спецификаций

Еще один элемент паззла - это наш базовый класс, в который мы выносим те или иные вспомогательные конструкции.

public class with_site_attendance_analyzer : specification
{
    public SiteAttendanceAnalyzer analyzer;
    public Mock<IAttendanceStatisticsProvider> billingDataProvider;
    public Resource resource;

    protected void attendance_statistics_analyzer()
    {
        resource = new Resource { Uri = new Uri("http://bdd.com/simplespect") };
        billingDataProvider = new Mock<IAttendanceStatisticsProvider>();
        analyzer = new SiteAttendanceAnalyzer(billingDataProvider.Object);
    }

    protected void attendance_statistics(params AttendanceSummary[] attendances)
    {
        billingDataProvider
            .Setup(provider => provider.FetchStatistics(resource, It.IsAny<DateTime>(), It.IsAny<DateTime>()))
            .Returns(attendances);
    }

    protected void attendance_statistics(
        DateTime startDate, 
        DateTime endDate, 
        params AttendanceSummary[] attendances)
    {
        billingDataProvider
            .Setup(provider => provider.FetchStatistics(resource, startDate, endDate))
            .Returns(attendances);
    }
}

Можно сказать, что стоит так или иначе скрывать все то, что не является описанием спецификации. Сокрытие осущетвляется путем выделения методов.

Код, который повторяется от сценария к сценарию, и не привносит смысловой нагрузки.
Детали реализации спецификации, низкоуровневая работа с API модуля.
Код, который представляет собой механизмы тестирования, к примеру, создание и конфигурация фейков.

Снова же, основная цель - разделение описания и реализации спецификации. Выделение базового класса - лишь механизм предоставления доступа разным сценариям к одним и тем же элементам. Если у вас всего два сценария, то скорее всего выделение базового класса неоправдано.

Выводы

Неважно какой фреймворк вы используете для описания спецификаций в BDD стиле. Важно понимать, что BDD - это прежде всего идея, подход, изменение мышления. Если выразить идею BDD одним предложением, то я бы сказал, что это переход от тестирования приложения к описанию поведения приложения. Понимание этого дает почву для рождения новых идей, и позволяет принимать осмысленные решения в спорных ситуациях. Какой BDD фреймворк или библиотеку Вы используете или не используете не важно, используйте то, что Вам больше всего нравится, с чем Вам проще работать, и то, что считаете оправданным.

Интересно также рассматривать идею Behavior-driven development в связке с Domain-driven design (DDD). DDD - позволяет коду модудей говорить на языке предметной области, BDD - позволяет коду тестов/cпецификаций говорить на языке предметной области. Идея BDD удачно гармонирует c DDD, но в тоже время вполне можно использовать BDD без применения DDD.

SNAP - Keeping aspects in a container

2011-10-06T02:05:00.003+03:00

Hi, this is my first blog post in English, as I want to share it with an English-speaking audience too. Today I want to speak about aspect oriented framework named SNAP, build simple logging aspect, then describe why it is bad to let SNAP manage aspects instances on its own, and how it restricts us as a developers in building complex aspects. Then I show how I've solved the problem described.

SNAP - Simple .NET Aspect-Oriented Programming

Recently I've been using SNAP, a yet another Aspect Oriented Programming framework for .NET. I've had a positive experience, and here are some key points to describe it.

Does not use code weaving, does not rewrite IL code to get interception mechanism to work. Instead uses Castle.DynamicProxy library features like subclassing, interface proxying.
Ability to intercept only selected methods, instead of intercepting all methods of a given class.
Integrates with a favorite DI/IoC container. Currently five implementations are supported: Autofac, Castle.Windsor, StructureMap, NInject, LinFu.
Provides unified model to program aspects regardless selected DI/IoC container implementation.
Lightweight and simple.

Sounds good, isn't it? If you are new to SNAP, I'd recommend to take a look at it. Here is a home page, and here is a source code, and nuget packages are also there.

Snap (Simple .NET Aspect-Oriented Programming) was conceived out of a recurring need for flexible AOP in the wake of PostSharp's metamorphosis into a commercial product.

Not to be mistaken with a code weaver (i.e. a compile-time tool), Snap is a fully run-time executed library. Snap aims to pair with your Inversion of Control (IoC) container of choice to deliver a powerful aspect-oriented programming model.

Logging aspect implementation

To show SNAP in a work, lets consider a simple scenario. Assume, we have a class CalculateRouteCommandHandler, which calculates a route between given two points A and B.

public class CalculateRouteCommandHandler
{
    public virtual void HandleCommand(CalculateRouteCommand command)
    {
        try
        {
            var intermediateroutes = CalculateIntermediateRoutes();
            foreach (var intermediateroute in intermediateroutes)
            {
                CalculateDistance(intermediateroute);
                CalculateTransport(intermediateroute);
                FindAlternatives(intermediateroute);
            }
        }
    }
}

Next, we want to log command started and completed events. Logging is a cross-cutting concern, so being aspect-oriented we need to encapsulate logging functionality in the form of aspect. From a SNAP implementation viewpoint, aspect is a class which inherits from the MethodInterceptor base class, and decorates target class with a custom behavior.

public class TraceCommand : MethodInterceptor
{
    public override void InterceptMethod(IInvocation invocation, MethodBase method, Attribute attribute)
    {
        var command = (Command) invocation.Arguments.First();
        var targetAttribute = (TraceCommandAttribute) attribute;

        // trace command start
        if(targetAttribute.TraceStart)
        {
           Logger.Info("Command started: {0}".FormatString(command));
        }

        // call target method
        invocation.Proceed();

        // trace command completion
        if(targetAttribute.TraceComplete)
        {
           Logger.Info("Command completed: {0}".FormatString(command));
        }
    }
}

Next we need to apply the aspect to the business code. We need an attribute class, and then apply it to the target method.

public class TraceCommandAttribute : MethodInterceptAttribute
{
    // these are settings which influence aspect behavior
    public bool TraceStart { get; set; }
    public bool TraceComplete { get; set; }
}

// do not trace command start event, just command completion one
[TraceCommand(TraceStart = false)]
public virtual void HandleCommand(CalculateRouteCommand command)
{
    // business logic goes here
}

Next step is to configure SNAP framework to let it know about our aspects and attributes, and what components do we want to intercept.

// using Autofac as a container implementation
var builder = new ContainerBuilder();

// configure aspects
SnapConfiguration.For(new AutofacAspectContainer(builder)).Configure(c =>
{
    c.IncludeNamespace("MyCommands.*");
    c.Bind<TraceCommand>().To<TraceCommandAttribute>();
});

// configure application components in container
builder.RegisterType<CalculateRouteCommandHandler>().As<ICommandHandler<CalculateRouteCommand>>();

And that's all you need to get SNAP to work.

Aspect management problem

So far so good. But you say: "Hey, this is a very simple scenario. Show us something more practical.". Ok. Let's try to identify some SNAP pitfalls with a bit more difficult scenario.

LoggingAspect uses static Logger class to get an access to logging functionality. I don't like logging to be exposed via static Logger class. I think, you are too. Instead I redesign it into ILoggingService service.

public interface ILoggingService
{
    void Debug(string message);
    void Info(string message);
    void Warn(string message);
    void Error(string message, Exception failure);
    void Fatal(string message, Exception failure);
}

Furthermore, I register ILoggingService in a my favorite container.

builder.RegisterType<LoggingService>().As<ILoggingService>();

In fact, aspect could be considered as a regular component, and rare component lives in an isolation. Usually, it has external dependencies. So now I'm going to make some refactoring in the LoggerAspect class, and switch using static Logger class to ILoggingService instead.

public class TraceCommand : MethodInterceptor
{
    private ILoggingService _loggingService;

    // ILoggingService is constructor injected in TraceCommand aspect class
    public TraceCommand(ILoggingService loggingService)
    {
        _loggingService = loggingService;
    }
        
    public override void InterceptMethod(IInvocation invocation, MethodBase method, Attribute attribute)
    {
        var command = (Command) invocation.Arguments.First();
        _loggingService.Info("Command started: {0}".FormatString(command));
        // other aspect code goes here
    }
}

The last step is to configure our new aspect with an external dependency in a SNAP. But here we run into a problem. SNAP allows to specify aspect type only, not the instance. There is no way to supply pre-built LoggerAspect instance to a SNAP.

SnapConfiguration.For(new AutofacAspectContainer(builder)).Configure(c =>
{
    c.IncludeNamespace("MyCommands.*");
    // no way to do it
    c.Bind(new TraceCommand(new LoggingService)).To<TraceCommandAttribute>();
});

To summarize the problem cause, SNAP manages aspect instances on his own. It creates a single instance for a given aspect type, and uses that instance for all interceptions. In other words, aspect is a singleton, and it is created by SNAP internally, without even letting developer to supply user-defined aspect instance. This is a significant problem, which impose several restrictions on how aspects are designed.

Aspect should have parameterless constructor.
External dependencies could not be injected in the aspect class. Aspect class can only refer to globally visible services (like singletons or static classes).
Another option is to make aspect class to be autonomous and let encapsulate all stuff required to get it to work. This way, we could end up with an enormously large aspect class with many responsibilities.

Keep and resolve aspects from container

So, now I want to share my solution to the problem described above. Recently I've implemented new feature, which allows developers to keep aspects in a container too, and let SNAP know whether aspect is managed by a container or should be instantiated by a SNAP (which is the default behavior). So, the idea is to let container manage components (aspects), and SNAP - to bring aspect-orientation and intercept method calls.

All aspects are managed by container

So, assume you have several aspects, which are managed by a container. Here is how you could tell SNAP about it.

[Test]
public void Autofac_Supports_Resolving_All_Aspects_From_Container()
{
    var builder = new ContainerBuilder();

    SnapConfiguration.For(new AutofacAspectContainer(builder)).Configure(c =>
    {
        c.IncludeNamespace("SnapTests.*");
        c.Bind<FirstInterceptor>().To<FirstAttribute>();
        c.Bind<SecondInterceptor>().To<SecondAttribute>();
        c.AllAspects().KeepInContainer();
    });

    builder.Register(r => new OrderedCode()).As<IOrderedCode>();
    builder.Register(r => new FirstInterceptor("first_kept_in_container"));
    builder.Register(r => new SecondInterceptor("second_kept_in_container"));

    using (var container = builder.Build())
    {
        var orderedCode = container.Resolve<IOrderedCode>();
        orderedCode.RunInOrder();

        // both interceptors are resolved from container
        CollectionAssert.AreEquivalent(
            OrderedCode.Actions,
            new[] { "first_kept_in_container", "second_kept_in_container" });
    }
}

This way SNAP uses a container to resolve aspect instances, whenever interception occurs.

Only subset of aspects are managed by container

In this scenario, some of your aspects are managed by container, while other are not. Once again, we need to tell SNAP about it.

[Test]
public void Autofac_Supports_Resolving_Only_Selected_Aspects_From_Container()
{
    var builder = new ContainerBuilder();

    SnapConfiguration.For(new AutofacAspectContainer(builder)).Configure(c =>
    {
        c.IncludeNamespace("SnapTests.*");
        c.Bind<FirstInterceptor>().To<FirstAttribute>();
        c.Bind<SecondInterceptor>().To<SecondAttribute>();
        c.Aspects(typeof(FirstInterceptor)).KeepInContainer();
    });

    builder.Register(r => new OrderedCode()).As<IOrderedCode>();
    builder.Register(r => new FirstInterceptor("first_kept_in_container"));
    builder.Register(r => new SecondInterceptor("second_kept_in_container"));

    using (var container = builder.Build())
    {
        var orderedCode = container.Resolve<IOrderedCode>();
        orderedCode.RunInOrder();

        // first interceptor is resolved from container, while second one is via new() 
        CollectionAssert.AreEquivalent(
            OrderedCode.Actions,
            new[] { "first_kept_in_container", "Second" });
    }
}

When nothing is configured explicitly, SNAP uses its default behavior and instantiates aspect instances on its own.

Conclusion

As you can see, it becomes possible to keep aspects in a container too, not only application components. These changes are already pulled into the main SNAP repository. So you can already use this IMO valuable feature.

Stay tuned. Happy aspecting.

Aspect Oriented Programming with SNAP

2011-10-05T02:13:00.002+03:00

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

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

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

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

Cross-cutting concerns
Aspect orientation
Классификация AOP framework'ов
Выбор AOP framework'а
SNAP - Simple .NET Aspect Oriented Programming

Cross-cutting concerns

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

public class CalculateRouteCommandHandler
{
    private IMapService _mapService;

    public CalculateRouteCommandHandler(IMapService mapService)
    {
        _mapService = mapService;
    }

    public void HandleCommand(CalculateRouteCommand command)
    {
        Logger.Info("{0} started.".FormatString(command));
        Logger.Info("From: {0}; To: '{1}'.".FormatString(command.Departure, command.Destination));

        try
        {
            var intermediateroutes = CalculateIntermediateRoutes();
            foreach (var intermediateroute in intermediateroutes)
            {
                CalculateDistance(intermediateroute);
                Logger.Debug("Distance calculated: {0}".FormatString(intermediateroute.Distance))

                CalculateTransport(intermediateroute);
                Logger.Debug("Transport calculated: {0}".FormatString(intermediateroute.Transport))

                var alternatives = FindAlternatives(intermediateroute);
                if(alternative.Any())
                {
                    Logger.Info("Found alternative routes: '{0}'".FormatString(alternatives))
                }
            }
            foreach (var jump in command.Jumps)
            {
                Logger.Info("{} completed".FormatString(command));
                Logger.Info("Jump from '{0}' to '{1}' with distance of '{2}'"
                    .FormatString(jump.Departure, jump.Destination, jump.Distance))
            } 
        }
        catch(RouteCalculationException ex)
        {
            Logger.Error("Fail to calculate route", ex);
            throw;
        }
    }
}

Класс состоит из одного метода, который чуть ли не на половину состоит из кода логгирования. Плохо то, что бизнес-логика приложения и инфраструктурные механизмы (в виде логгирования) перемешаны. Инфраструктурные детали, будучи сугубо техническими, засоряют основной код приложения, который выражает требования бизнеса. Даже при относительно небольшом проценте инфраструктурного кода, читать и понимать бизнес задачи, которые этот код призван решать и выражать, становится сложно. Распространенность этого подхода обусловлена легкостью реализации, но отнюдь не соображениями о правильной архитектуре, и оценке последствий такого решения.

Определим понятие cross-cutting concerns (сквозная функциональность).

In software development cross-cutting concerns are logical parts of the program that affect (crosscut) other concerns or modules.

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

Безопасность
Поддержка транзакционности
Обработка ошибок
Поддержка многопоточности
Измерение производительности
Логгирование

Если представить слоистую архитектуру приложения, состоящую из presentation, application, domain и infrastructure слоев, расположенных горизонтально друг над другом, то сквозная функциональность не имеет отношения ни к какому конкретному слою, а пересекает все слои вертикально. Отсюда и название - сквозная функциональность.

Aspect orientation

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

Никто не отменял такие принципы, как Don't repeat yourself, Single Responsibility Principle, Separation Of Concerns. Собственно идеей Aspect Oriented Programming и является отделение сквозной функциональности от бизнес-логики приложения (separation of concerns), и поощрение принципов DRY и SRP.

public class CalculateRouteCommandHandler
{
    private IMapService _mapService;

    public CalculateRouteCommandHandler(IMapService mapService)
    {
        _mapService = mapService;
    }

    [TraceCommand]
    public virtual void HandleCommand(CalculateRouteCommand command)
    {
        try
        {
            var intermediateroutes = CalculateIntermediateRoutes();
            foreach (var intermediateroute in intermediateroutes)
            {
                CalculateDistance(intermediateroute);
                CalculateTransport(intermediateroute);
                FindAlternatives(intermediateroute);
            }
        }
    }

    [TraceCall(Format = "Distance calculated: {1}", Level = LogLevel.Debug)]
    protected void virtual CalculateDistance(Route intermediate)
    {
        ...
    }

    [TraceCall(Format = "Transport calculated: {1}", Level = LogLevel.Debug)]
    protected void virtual CalculateTransport(Route intermediate)
    {
        ...
    }

    [TraceCall(Format = "Alternatives found: {1}", Level = LogLevel.Info, LogStart = false)]
    protected void virtual FindAlternative(Route intermediate)
    {
        ...
    }
}

HandleCommand метод более не засорен деталями логгирования и описывает исключительно бизнес задачу. Логгирование применено посредством аспектов. Аспект представляет из себя тот или иной элемент сквозной функциональности. Аспекты TraceCommand и TraceCall выполняют логгирование события обработки команд и вызова методов соответственно.

Классификация AOP framework'ов

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

AOP фреймворки можно классифицировать по следующим критериям:

Каким образом осуществляется перехват кода и вызов аспектов?
В какие элементы кода можно внедрять аспекты?
Каким образом можно применять аспекты к коду приложения?

Первый подход состоит в интрументировании IL-кода сборки на этапе пост-компиляции (code weaving) путем внедрения кода вызова аспектов в нужных места кода приложения. Основной представитель этого класса фреймворков - PostSharp.

With PostSharp, software developers can encapsulate implementation patterns into classes called aspects, and apply these aspects to their code using custom attributes.

С другой стороны, можно обойтись и без низкоуровневого изменения IL-кода, а вместо этого использовать run-time средства, такие как subclass либо interface proxy. Идея состоит в прозрачной для клиента подмене реальных классов прокси-классами, которые помимо вызова проксируемого класса добавляют поведение вызова нужных аспектов. Библиотека Castle.DynamicProxy предоставляет механизм создания таких прокси и перехвата виртуальных методов.

Castle DynamicProxy is a library for generating lightweight .NET proxies on the fly at runtime. Proxy objects allow calls to members of an object to be intercepted without modifying the code of the class. Both classes and interfaces can be proxied, however only virtual members can be intercepted.

Целью перехвата обычно служит вызов метода. Реже - вызов поля, более того, вызов поля всегда можно смоделировать в виде вызова метода, так что основной use case - это перехват метода (method interception). Фреймворки, которые инструментируют сборку путем переписывания кода, позволяют внедрить перехват в любое место, будь то вызов метода или поля. Минус состоит, во-первых, в самой идее переписывания скомпилированного кода, во-вторых, в увеличении времени компиляции и сборки, а также сложности настройки и громоздкости этого процесса. Подход, который не требует инструментирования сборки, выглядит более заманчивей. В тоже время, он позволяет перехватывать только виртуальные public/protected методы. Если же компоненты в приложении управляются контейнером, то возможности перехвата сужаются еще и до списка зарегистрированных компонент. У подхода с инструментированием сборки этих ограничений нет.

Наиболее предпочительный способ применения аспектов к коду приложения (например, методам или классам) непосредственно в том же коде при помощи атрибутов. Также можно описывать применение аспектов в отдельном xml файле, либо с помощью графического дизайнера. Однако в таком случае становится сложнее анализировать код, так как приходится смотреть в несколько мест, и использовать для этого разные языки либо инструменты.

Выбор AOP framework'а

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

Не предполагает переписывание скомпилированного кода и инструментирование сборки.
Позволяет выборочно осуществлять перехват на уровне методов.
Интегрируется с выбранным DI/IoC контейнером.
Приемлемый с точки зрение призводительности и продуктивности разработчика.

PostSharp - известный, зрелый иструмент. Однако, идея переписывания IL-кода не прельщает, и хочется избежать сложностей post-build настройки проектов. Заметно увеличивается время сборки проекта. Помимо этого, Postsharp - это платный инструмент, хотя в наличии есть и бесплатная Starter Edition с урезаным функционалом. Вобщем, PostSharp - это тяжелая артиллерия, без которой можно обойтись в большинстве use case'ов.

Использовать Castle.DynamicProxy напрямую слишком хлопотно, и в итоге придется создавать поверх него собственный вспомогательный слой. Но нам нужно заниматься бизнем задачами, а не созданием инфраструктуры. Ниже код создания прокси для класса либо интерфейса c указанием interceptor'ов.

public static object CreateProxy(Type interfaceType, object instanceToWrap, params IInterceptor[] interceptors)
{
    if (interfaceType.IsInterface)
        return new ProxyGenerator().CreateInterfaceProxyWithTargetInterface(
            interfaceType, 
            instanceToWrap, 
            interceptors.ToArray());

    var ctor = type.GetConstructors().OrderBy(x => x.Parameters().Count).LastOrDefault();
    var ctorArgs = ctor == null ? new object[0] : new object[сtor.Parameters().Count];
    return new ProxyGenerator().CreateClassProxyWithTarget(
        interfaceType, 
        instanceToWrap, 
        ctorArgs, 
        interceptors);
}

Если для управления компонент в приложении применяется DI/IoC контейнер, то популярные контейнеры, такие как Castle.Windsor, Autofac, StructureMap и др., предоставляют функциональность перехвата вызова компонент зарегистрированных в контейнере. Для этого используется Castle.DynamicProxy как низкоуровневый механизм, однако детали работы с ним в той или иной мере скрыты от разработчика. Рассмотрим этот вариант на примере Autofac.

builder.RegisterType<BarCommandHandler>()
    .Keyed<ICommandHandler>(typeof(BarCommand))
    .SingleInstance()
    .EnableClassInterception();
builder.RegisterType<BazCommandHandler>()
    .Keyed<ICommandHandler>(typeof(BazCommand))
    .SingleInstance()
    .EnableInterfaceInterception();

Магия состоит в использовании extension методов EnableClassInterception и EnableInterfaceInterception, которые находится в библиотеке AutofacContrib.DynamicProxy2. Исходный код можно посмотреть здесь.

Минус состоит в том, что приведенным выше образом можно сконфигурировать перехват всех методов указанного класса, но без возможности конфигурации на уровне отдельных методов. И это существенный недостаток! Редко когда нужно перехватывать все методы класса без разбора. В качестве workaround, здесь и здесь описываются подходы как реализовать это самому.

Подведя итог обзора доступных AOP решений, с одной стороны есть тяжелый и сложный, к тому же платный PostSharp, с другой стороный есть низкоуровненый механизм Castle.DynamicProxy, напрямую работать с которым будет неудобно. Наиболее привлекательным решением выглядит использование возможностей поставляемых с DI/IoC контейнерами, однако поведение и возможности варьируются в зависимости от выбранного поставщика. Например, в том же Autofac, нет out-of-the-box возможности выборочного перехвата методов.

SNAP - Simple .NET Aspect Oriented Programming

Далее рассмотрим возможности AOP фреймворка под названием SNAP. Более подробно здесь.

A .NET library to make aspect-oriented programming a Snap!

Snap (Simple .NET Aspect-Oriented Programming) was conceived out of a recurring need for flexible AOP in the wake of PostSharp's metamorphosis into a commercial product.

Not to be mistaken with a code weaver (i.e. a compile-time tool), Snap is a fully run-time executed library. Snap aims to pair with your Inversion of Control (IoC) container of choice to deliver a powerful aspect-oriented programming model.

Итак, в чем отличие этого решения от тех что обсуждались ранее? Опишем плюсы этого решения:

Для реализации механизма перехватов не производится инструментирование сборки на этапе пост-компиляции, вместо этого используется возможности Castle.DynamicProxy (subclass/interface proxy)
Интеграция с DI/IoC контейнером. На данный момент поддерживается пять реализаций: Autofac, Castle.Windsor, StructureMap, NInject, LinFu.
Использование единой программной модели независимо от выбранного поставщика DI/IoC, скрытие от разработчика специфики его работы с возможностями перехвата.
Выборочный перехват методов.
Проста в использовании. Не требует от разработчика понимать реализацию таких advanced концепций, как dynamic proxies, и как интегрировать их в используемый DI/IoC контейнер.

Проект выложен на github, а также доступен для установки на nuget gallery.

Реализация аспекта логгирования

Далее рассмотрим реализацию логгирования в AOP ключе используя для этого SNAP. Бизнес-логика находится в классе CalculateRouteCommandHandler, который расчитывает маршрут между двумя пунктами.

public class CalculateRouteCommandHandler
{
    private IMapService _mapService;

    public CalculateRouteCommandHandler(IMapService mapService)
    {
        _mapService = mapService;
    }

    public virtual void HandleCommand(CalculateRouteCommand command)
    {
        try
        {
            var intermediateroutes = CalculateIntermediateRoutes();
            foreach (var intermediateroute in intermediateroutes)
            {
                CalculateDistance(intermediateroute);
                CalculateTransport(intermediateroute);
                FindAlternatives(intermediateroute);
            }
        }
    }

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

public class TraceCommand : MethodInterceptor
{
    public override void InterceptMethod(IInvocation invocation, MethodBase method, Attribute attribute)
    {
        var command = (Command) invocation.Arguments.First();
        var targetAttribute = (TraceCommandAttribute) attribute;
        try
        {
            if(targetAttribute.TraceStart)
            {
                Logger.Info("Command started: {0}".FormatString(command));
            }
            invocation.Proceed();
            if(targetAttribute.TraceComplete)
            {
                Logger.Info("Command completed: {0}".FormatString(command));
            }
        }
        catch(Exception ex)
        {
            if(targetAttribute.TraceFail)
            {
                Logger.Error("Command failed: {0}".FormatString(command), ex);
            }
            throw;
        }
    }
}

Класс аспекта наследуется от базового класса MethodInterceptor, в котором есть методы BeforeInvocation(), AfterInvocation(). Если нужен доступ к информации о вызове, вызванном методе, атрибуте, то можно переопределить метод InterceptMethod, как это показано выше. Тело метода состоит из логгирования начала команды, удачного либо неудачного ее завершения. Вызов же самого целевого метода осуществляется при помощи IInvocation.Proceed().

Применение аспекта

После того как класс аспекта с логикой сквозной функциональности готов, необходим механизм применения аспекта к коду приложения. Для этого нам нужен атрибут.

public class TraceCommandAttribute : MethodInterceptAttribute
{
    public bool TraceStart { get; set; }
    public bool TraceComplete { get; set; }
    public bool TraceFail { get; set; }
}

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

[TraceCommand(TraceStart = false)]
public virtual void HandleCommand(CalculateRouteCommand command)
{
    // business logic goes here
}

Конфигурация аспектов

Далее нужно сконфигурировать SNAP таким образом, чтобы он знал о реализованных аспектах и атрибутах, которые используются для применения аспектов. В простейшем случае это выглядит так (на примере Autofac).

var builder = new ContainerBuilder();

// configure aspects
SnapConfiguration.For(new AutofacAspectContainer(builder)).Configure(c =>
{
    c.IncludeNamespace("MyCommands.*");
    c.Scan(s => s.ThisAssembly().WithDefaults());
});

// configure components in container
builder.RegisterType<CalculateRouteCommandHandler>().As<ICommandHandler<CalculateRouteCommand>>();
builder.RegisterType<MapService>().As<IMapService>();

Первым делом указываем осуществлять перехват только тех классов, которые находятся в указанном namespace. Минус - это отсуствие типизации в данном случае, так как название неймспейса - это простая строка. Далее конфигурируем SNAP так, чтобы он сам определил набор аспектов и их атрибутов, используя naming convention - название класса аспекта должно совпадать с названием класса атрибута (без учета суффиксов "Interceptor", "Attribute"). Также можно подключить свою собственную стратегию автоматической конфигурации компонент, реализовав интерфейс IScanningConvention. В нашем примере default naming convention выполняется, поэтому нет необходимости явно конфигурировать TraceCommandAspect. В противном случае это можно сделать так.

SnapConfiguration.For(new AutofacAspectContainer(builder)).Configure(c =>
{
    c.IncludeNamespace("MyCommands.*");
    c.Bind<TraceCommand>().To<TraceCommandAttribute>();
});

Один метод - много аспектов

Можно ли к одному методу применить несколько аспектов? Ответ: "Да". В таком случае, порядок выполнения аспектов важен. Порядок указания атрибутов в исходном коде не может быть использован в принципе, поэтому есть два механизма конфигурации порядка вызова аспектов: для аспекта в целом, и для отдельного случая его применения.

SnapConfiguration.For(new AutofacAspectContainer(builder)).Configure(c =>
{
    c.IncludeNamespace("MyCommands.*");
    // configure ordering for any aspect usage
    c.Bind<TraceCommand>().To<TraceCommandAttribute>().Order(2);
});

// configure ordering just for this usage
[TraceCommand(TraceStart = false, Order = 2)]
// handle error first of all
[HandleError(Order = 1)]
public virtual void HandleCommand(CalculateRouteCommand command)
{
    // business logic goes here
}

Если порядок не указан тем или иным образом, аспекты выполняются в алфавитном порядке по названию класса.

Вот собственно и все, что нужно для применения aspect oriented подхода используя SNAP в качестве фреймворка.

Недостаток SNAP

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

public interface ILoggingService
{
    void Debug(string message);
    void Info(string message);
    void Warn(string message);
    void Error(string message, Exception failure);
    void Fatal(string message, Exception failure);
}

Этот интерфейс инжектится в класс аспекта и далее используется для логгирования вместо статического класса Logger.

public class TraceCommand : MethodInterceptor
{
    private ILoggingService _loggingService;

    public TraceCommand(ILoggingService loggingService)
    {
        _loggingService = loggingService;
    }
        
    public override void InterceptMethod(IInvocation invocation, MethodBase method, Attribute attribute)
    {
        var command = (Command) invocation.Arguments.First();
        _loggingService.Info("Command started: {0}".FormatString(command));
        // other aspect code goes here
    }
}

Более того, компонент ILoggingService управляется контейнером.

builder.RegisterType<LoggingService>().As<ILoggingService>();

Вопрос: А как же теперь сконфигурировать SNAP? Если позволить найти аспект автоматически, то SNAP не сможет создать экземпляр аспекта не найдя конструктора без параметров. Возможности же явно указать готовый экземпляр аспекта тоже нет. B итоге приходится возвращаться к реализации аспекта со статическим классом Logger.

Keep aspects in container

Подведя итог, проблема состоит в том, что SNAP сам занимается созданием и управлением экземпляров аспектов. В итоге, аспекты - это синглтоны, созданные на этапе конфигурации SNAP. Это влечет за собой невозможность использования аспектов, которым нужны внешние сервисы для работы. А значит, мы ограничены созданием очень простых аспектов, либо автономных и самодостаточных классов аспектов, в которых есть все, что нужно им для работы. Это нарушает Single Responsibility Principle и не поощряет использование good design practices. А хороший фреймворк хорош тогда, когда поощряет разработчика к применению лучших практик.

Печально, но по крайней мере для меня, эта проблема сводит на нет все преимущества этого фреймворка. Поэтому я решил исправить положение вещей и дать возможность контейнеру управлять классами аспектов, и позволить SNAP запрашивать экземпляры аспектов у контейнера, вместо того чтобы создавать их самому. Таким образом каждый будет заниматься тем, что у него получается лучше всего: SNAP - аспектами и перехватами, а контейнер - управлением компонентами. В ближайшем будушем я планирую закончить реализацию этой функциональности и отправить pull request в основной репозиторий.

Stay tuned!

Behavior Driven Development Explained with MSpec

2011-09-25T04:07:00.003+03:00

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

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

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

From unit testing to behavior specifications
Использование MSpec - BDD framework in context-specification style
Conclusion

From unit tests to behavior specifications.

Goal of unit testing and drawback analysis

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

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

Юнит тест представляет собой смесь состоящую из бизнес задач и механизмов тестирования этих задач. К бизнес задачам можно отнести совершение тех или иных действия в заданном контексте, проверка их результата (это то, ЧТО мы тестируем). Механизмы тестирования - это mocking frameworks, assertion libraries, все то, что позволяет осуществлять верификацию результата (это то, КАК мы тестируем). Эта смесь усложняет чтение тестов и будущую их поддержку, так как нужно постоянно отделять бизнес специфику от деталей механизмов тестирования. Это приводит к тому, что тесты не сопровождаются должным образом, становясь балластом, начиная приносить больше вреда чем пользы.

В погоне за упрощением юнит теста, разработчики структуриют тело теста, например, используя Four Phase Test Approach, либо Arrance-Act-Assert. Идея состоит в логическом разделении тела метода на части. Разбиение происходит в терминах механизма тестирования, а не в терминах бизнес специфики: инициализация теста, подготовка тестируемого объекта, совершение действий над объектом, верификация результата. Структурирование набора тестов происходит обычно по принципу Test Case Per Class, либо же Test Case Per Feature.

Отбросив технические сложности, такие как плохая читабельность, сложность сопровождения, то основным концептуальным недостатком, независимо от применения test-last либо test-first development'а, является то, что юнит тест позволяет проверить то, что созданное ПО работает корректно, но отнюдь не то, что ПО является корректным.

Executable specifications

Размышления над вопросом "Что значит сделать корректное ПО?" приводят к понятию поведения, спецификации требований. Корректное ПО - такое ПО, поведение которого соответсвует предъявленным ему требованиям. Идея BDD подхода в описании требований (спецификаций), которые могут быть выполнены - executable specifications. Вместе с тем, executable specification наследуют все свойства юнит тестов: repeatable, independent, thorough, maintainable, fast, automatic, professional, readable. Основное отличие от юнит тестов в том, что юнит тест верифицирует правильность работы модуля, а executable specification - описывает желаемое поведение модуля. Описывая поведение модуля, спецификация привязана к API модуля в меньшей степени. Так как поведение меняется значительно реже чем API модуля и сам модуль, то и частота обновления спецификаций ниже, чем частота обновления юнит тестов.

Given-when-then

Использование конструкций given-when-then является методикой структурирования тела спецификаций. Однако, если подходы Four Phase Test Approach, либо Arrance-Act-Assert фокусировались на разбиении теста в терминах механизмов тестирования, то части спецификации given/when/then выражены в терминах бизнеса. Вместо инициализации теста и подготовке объекта мы думаем о контексте, в рамках которого происходит операция (given), вместо вызова методов думаем о сути выполняемой операции (when), вместо тестирования результатов - думаем о поведении (then). Помимо концептуального различия, такой given-when-then подход служит для унификации языка описания спецификаций.

Scenarios and context/specification style

Применение BDD подхода в самой малой его толике - это именование юнит тестов таким образом, чтобы оно описывало поведение тестируемого аспекта. Для названия обычно тоже применяется тот же шаблон given-when-then, либо его разновидности.

Однако BDD - это нечто большее. BDD предполагает выделение поведения как отдельной концепции. Поведения в свою очередь проявляются при каких-то условиях. Набор таких условий определяет сценарий. Сontext/Specification стиль предлагает рассматривать поведения не как плоский список, а фокусироваться на различных сценариях, в рамках которых проявляются те или иные поведения. Следствием такого подхода является то, что одно и тоже поведение может проявлятся в разных сценариях. BDD framework'и в отличие от unit testing framework делают явный акцент на поведениях, сценариях, а не на механике тестирования.

Flavors of BDD approach

BDD подход можно разделить на два вида: xSpec и xBehave.

xSpec - это применение BDD на уровне модулей (unit level), то есть описание спецификаций по отношению к модулям. Обычно используются те же технические инструменты, что и для написания юнит тестов (mocking frameworks, assertion libraries, unit test frameworks). Некоторые BDD framework'и предлагают описывать спецификации, на основании которых потом генерируется код тестов, то есть разделять описание спецификации и реализацию. Думаю, что такая практика неприменима для unit-level спецификаций. Так как единственной ролью, которая работает со спецификациями, путем их описания и реализации, является разработчик, то разделять описание и реализацию спецификации в два разных места не стоит. Более привлекательным выглядит подход, когда описание может быть сгенерировано отдельно на основании кода спецификации, например в виде отчета. Unit-level спецификации применимы на этапе дизайна и реализации ПО, например, как замена стандартных юнит тестов.
Примеры фреймворков: MSpec, NSpec.

xBehave - это применение BDD для описания высокоуровневых пользовательских историй (user stories) в виде приемочных критериев (acceptance criteria) при помощи given-when-then синтаксиса. Охватывает этап сбора и анализа требований, а также этап дизайна. Такой подход пропагандирует описание спецификаций одной ролью, например аналитиком либо тестировщиком, а реализацию уже разработчиком. Тут уже становится оправданным разделить описание и реализацию спецификаций, например в виде текстового файла с историями и автоматической кодогенераций тестов. В таком случае сложно обеспечивать синхронизацию текста историй и сгенерированного кода тестов. Также возникает сложность в реализации тестов. А именно, как реализовать проверку спецификации таким образом, чтобы не потерять свойств юнит тестов (repeatable, independent, thorough, maintainable, fast, automatic, professional, readable). Если же уровень спецификации - пользовательская история, то проверка может вовлечь в себя взаимодействие систем или подсистем. А значит, в лучшем случае - это будет интреграционный тест. И возможно ли вообще в этом случае сделать автоматический тест? Также предполагается переход от story-level спецификаций к unit-level спецификациям. Насколько этот переход будет бесшовным, и будет ли в нем польза - тоже остается для меня пока вопросом.
Примеры фреймворков: NBehave, SpecFlow.

Использование MSpec

Далее рассмотрим воплощение идей BDD на реальных примерах, взятых из гипотетической бухгалтерской системы одного приложения с использованием MSpec. Данный раздел не является исчерпывающим руководством по использованию MSpec. Здесь я хочу лишь показать как использовался MSpec, и насколько он применим в тех или иных сценариях.

Пример спецификации в стиле context/specification.

Спецификация состоит из установления контекста (given), в MSpec для этого применяется делегат Establish, выполнения бизнес операции (when), при помощи делегата Because, и наконец верификации поведения (then), при помощи делегатов It. Given и when (Establish, Because) компоненты формируют сценарий, в котором наблюдается то или иное поведение (It).

[Subject(typeof(Shipment))]
public class When_applying_postage_info_from_external_source
{
    Establish _ = () => shipment= InitializePackaging(
        ShippingInfo.Create(PostalService.UA, true, Shape.POSTCARD, new 20.44m.Dollars());
    Because of =()=> pack.ApplyExternalPostage();

    It should_override_shipping_cost =
        () => shipment.PostageCost.ShouldEqual(new PriceInfo(20.44m, Currency.USD));
    It should_not_override_postal_service =
        () => shipment.PostalService.ShouldEqual(PostalService.UA);

    static Shipment shipment;
}

[Subject(typeof(Shipment))]
public class When_applying_postage_info_for_album_which_is_shipped_via_usps_pm
{
    Establish _ =()=> shipment = InitializePackaging("USPS-PM", 20.44m.Dollars()));
    Because of = () => shipment.ApplyExternalPostage();

    It should_override_shipping_cost =
        () => shipment.InternalCost.ShouldEqual(new PriceInfo(20.44m, Currency.USD));

    static Shipment shipment;
}

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

Тех, кто привык писать юнит тесты смущает, что на каждый тест приходится писать новый класс. Однако если взглянуть на то, что это не тест, а законченный сценарий (контекст + наблюдаемые поведения), то можно оправдать overhead создания нового класса в целях моделирования отдельного сценария. На самом деле, ничего криминального в подходе class-per-specification на мой взгляд нету. Это не production code, наличие большого количества классов не увеличивает сложность приложения, так как каждый из таких классов независим друг от друга, эти классы не объединяются в модули с внутренними зависимостями между собой. Для понимания набора спецификаций не нужно анализировать граф зависимостей, спецификации автономны, и представляют скорее плоский список. Также, как показывает практика, при переходе от тестов к спецификациям, их количество уменьшается, засчет того, что количество возможных сценариев в большинстве случаев будет меньше количества сценариев умноженных на уникальное количество поведений (юнит тесты).

Также слышна критика в адрес MSpec касательно применения делегатов и конструкций "=()=>". Тем не менее, функциональный подход позволяет сделать спецификации self-descriptive, давая внятные имена делегатам (It should_override_shipping_cost). Хотя в NSpec например применяется несколько другой подход. Больше смущает то, что классы и его члены смоделированы как static.

Failure verification

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

[Subject(typeof(Shipment))]
public class when_verifying_delivery_for_shipment_without_external_postage_info_specified
{
    Establish _ = () => packaging = InitializePackaging(PostalService.USPS, true, null);
    Because of = () => failure = Catch.Exception(() => shipment.VerifyDelivery());

    It should_fail = () =>
    {
       failure.ShouldBeOfType(typeof(DeliveryVerificationFailed));
       failure.Message.Should.Be("Delivery verification failed due to non existent postage info/");
    }

    static Shipment shipment;
    static Exception failure;
}

Для проверки того, что операция не может быть выполнена, приходится совершать много телодвижений. Во-первых, нужно, определить статическое поле типа Exception, которое будет хранить информацию об ошибке. В делегате Because нужно применить кунг-фу конструкцию Catch.Exception, также которая подразумевает использование делегата. В итоге получается конструкция из двух вложенных делегатов, которая отнюдь не поражает нас читабельностью. В конце концов, в делегате It нужно проверить что это именно та ошибка, которая подразумевается сценарием. Для сравнения, конструкция проверки ошибочной ситуации в классическом юнит тесте (используется FluentAssertions).

[Then]
public void test_for_operation_failure()
{
    analyzer.Invoking(a => a.IsFirstBillingRun(new DateTime(2011, 6, 1)))
        .ShouldThrow<ArgumentException>()
        .WithMessage("Client was not billed on", ComparisonMode.Substring);
}

Simple context

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

[Subject(typeof(PostalService))]
public class when_postal_service_is_parsed_from_string_with_postal_service_and_mail_class_separated_by_hyphen
{
    static PostalServiceservice;
    Because of = () => service = PostalService.Parse("USPS-FCM");

    It should_use_first_part_of_string_before_hyphen_as_postal_service =
        () => service.PostalService.ShouldEqual("USPS");
    It should_use_second_part_of_string_after_hyphen_as_mail_class =
        () => service.MailClass.ShouldEqual("FCM");
}

Action-common and context-common scenarios

Обычно несколько спецификаций можно сгруппировать по общим признакам.

Выполняется одна и та же операция, но меняется контекст.
Контекст один и тот же, но меняется операция.

Эту особенность можно использовать и вынести общую часть за скобки, тем самым разгрузив спецификацию от повторяющихся деталей, которые подразумеваются по умолчанию. Например, как в данном context-common scenario.

 
public class with_weight_calculator
{
    Establish _ = WeightCalculator;

    private static void WeightCalculator()
    {
        deviceWeightProvider = MockRepository.GenerateStub<DeviceWeightProvider>();
        boxSelector = MockRepository.GenerateStub<BoxSelector>();
        postageCalculator = new WeightCalculator(
            deviceWeightProvider ,
            boxSelector)
    }

    static WeightCalculator weightCalculator;
    static BoxSelector boxSelector;
    static DeviceWeightProvider deviceWeightProvider;
}

[Subject(typeof(PostageCalculator), "external shipping cost calculation")]
public class when_calculating_weight_for_medium_device_packed_into_safebox : with_weight_calculator
{
    Establish context = () =>
    {
        device = Device.New(new Client(1, "1"), "Notebook")
            .WithBoxingInfo("Safe") 
            .Build();
    };
    Because of = () => weight= weightCalculator.CalculateWeight(order);

    It should_be_greather_than_1kg =()=> weight.Should().BeGreather(1.Kilograms());

    static Device device;
    static Weight weight;
}

MSpec позволяет выделять общие части сценария поднимая их в базовый класс. Когда несколько сценариев разделяют общий контекст, я предпочитаю базовый класс называть по шаблону "with_{COMMON_CONTEXT}". Если разделяется общая операция - то по шаблону "when_{COMMON_ACTION}".

Можно вынести как Establish, так и Because, а также общие члены, которые используются в сценарии. Однако не все то, что делать можно, делать стоит. Введение иерархии наследования сильно связывает классы, и на это должна быть весомая причина. К примеру есть общий контекст, повторяющийся от спецификации к спецификации, который подразумевается по умолчанию, и описательная сила спецификации не уменьшится, если разнести создание контекста по разным местам. Важно помнить, что спецификация должна быть читабельной, и коммуницировать разработчику поведение. Если для того чтобы понять, что имелось ввиду, приходиться ходить по 3-уровневой иерархии наследования, то это не true. Я бы не выходил за рамки 2-уровневой иерархии для структурирования спецификаций. Двух уровней должно быть достаточно.

Behavior specification suite

Есть случаи, в которых применение context\specification style представляется излишней сложностью. Например, нужно проверить простое поведение, сценарий в предельно просто и неразрывно связан с поведением, например вызов метода и проверка его результата. В таком случае не хочется создавать много классов с двумя строчками кода в каждом. Например.

[Subject(typeof(Weight))]
public class When_converting_weight
{
    It should_convert_ounces_to_grams_according_to_coefficient =
        () => new Weight(1, Weight.Ounce).ConvertToGramms()
            .ShouldEqual(new Weight(1 / gram_to_ounce_coefficient, Weight.Gram));
    It should_convert_grams_to_ounces_according_to_coefficient =
        () => new Weight(1, Weight.Gram).ConvertToOunces()
            .ShouldEqual(new Weight(1 * gram_to_ounce_coefficient, Weight.Ounce));
    It should_do_nothing_when_converting_grams_to_grams =
        () => new Weight(1, Weight.Gram).ConvertToGramms().ShouldEqual(new Weight(1, Weight.Gram));
    It should_do_nothing_when_converting_ounces_to_ounces =
        () => new Weight(1, Weight.Ounce).ConvertToOunces().ShouldEqual(new Weight(1, Weight.Ounce));

    const decimal GRAM_TO_OUNCE_KOEFFICIENT = 0.03527m;
}

В таком случае легче просто описать список поведений, которые неявно включают в себя контекст и операцию, чем выделять эти шаги отдельно, и моделировать каждое поведение в виде отдельного класса.

Behavior/scenario specification style

Иногда нужно проверить, что отдельно взятое поведение, проявляется в разных сценариях. Если сравнивать с context/specification style, где мы движемся от сценария к поведениям, которые в нем наблюдаются, то в данном случае, мы движемся в обратном направлении - от поведения к сценариям, в которых оно проявляется либо не проявляется. Например.

[Subject(typeof(PostalService))]
public class postal_service_is_considered_to_be_more_expensive
{
    It is_usps_priority_mail = () => ShippingInfo.Builder
        .New(PostalService.USPS, MailClass.PRIORITY_MAIL).Build()
        .IsPremium.ShouldBeTrue();
    It is_russin_post_fast = () => ShippingInfo.Builder
        .New(PostalService.RUS, MailClass.FAST).Build()
        .IsPremium.ShouldBeTrue();
    It is_ukraine_post = () => ShippingInfo.Builder
        .New(PostalService.UAPOST).Build()
        .IsPremium.ShouldBeTrue();
}

Происходит проверка одного и того же поведения (shipping service should be premium) в разных сценариях (when usps priority mail, when fedex, etc.). Если бы мы применили context/specification style, то получили бы четыре сценария. MSpec, будучи context/specification фреймворком, не поддерживает behavior/scenario стиль. Пример приведенный выше - это лишь попытка использовать существующие средства для описания описания спецификации в behavior/scenario стиле.

Pros and cons of MSpec

Подведем итог, сформулируем плюсы и минусы использования MSpec в behavior-driven-development'е.

Pros:

MSpec - фреймворк который был специально построен для поддержки BDD стиля, а значит впитал в себя его идеи. В противоположность unit-testing фреймворкам, где разработчик волен сам выбирать стиль написания юнит тестов, использование MSpec принуждает разработчика именно к behavioral стилю. Это может быть как плохо так и хорошо, в зависимости от того, насколько жесткие правила и ограничения фреймворк накладывает на разработчика. Явно позиционируется фокус на спецификацию поведения, а не тестирования функциональности.
Инструментальная поддержка. Интеграция с ReSharper.
Описание спецификации и ее реализация не разделены (разные файлы), как это обычно делается в xBehave BDD framework'ах.
Поддержка вынесения общего контекста или общей операции "за скобки" путем поднятия делегатов Establish, Because в базовый класс.

Cons:

Использование static классов.
Синтаксический шум. Чрезмерное использование делегатов приводит к появлению громоздких синтаксических конструкций, в которых теряется бизнес специфика.
Низкий уровень readability для средних и больших спецификаций. Небольшие спецификации компактны и читабельны, но с увеличением размера спецификации читабельность резко ухудшается.
Смесь бизнес и технических деталей в теле спецификации. По сравнению с юнит тестами, бизнес специфика явно утверджается при помощи имен классов и делегатов, но по-прежнему перемешана с механизмами тестирования (использование mocking framework'ов, assertions libraries, создание/подготовка объекта).
Отсуствие поддержки behavior-scenario стиля описания спецификаций.

Conclusion

BDD - идея и реализация

Что касается перехода от unit-testing к behavior-driven development, стоит различать две вещи: идея, концепция и ее реализация. BDD как идея и концепция мне нравится, это сдвиг мировоззрения по сравнению с применением стандартного подхода юнит-тестирования. Использование же существующего фреймворка, такого как MSpec, показывает в свою очередь и определенные минусы. Однако это не повод отбрасывать идею вовсе. Когда я показываю спецификации, написанные на MSpec, другим разработчикам, то сразу возникают вопросы: "А что: каждый тест - это класс?", "А почему классы статические?", "Что за =()=>?". Не увидев за этими деталями реализации саму идею и принципы BDD, разработчик отворачивается от этого подхода и вовсе, приводя в качестве аргументов "против" неудавшиеся детали реализации.

Benefits

Моя личная практика использования BDD-подхода, в context/specification style, привела следующим наблюдениям:

Уменьшение количества сценариев по отношению к количеству юнит-тестов.
Поведения группируются относительно сценариев в которых они проявляются. Легче стало проверять одно и тоже поведение, которое проявляется в разных сценариях.
Легче стало применять spec(test)-first подход. Описания спецификаций меньше привязаны API модуля, чем юнит тесты.
Спецификации легче в сопровождении. Возвращаясь через некоторое время к спецификации, бывает достаточно прочитать ее описание для понимания поведения, и реже для этого приходиться лезть в код модуля.

SimpleSpec - simple unit-level BDD framework for .net

Те, кто принял идею BDD, и кого не устраивают существующие реализации, могут создать свой фреймворк на основании используемой ими unit-testing library. Слово фреймворк может в этом случае звучать пафосно, так как он может состоять всего из одного класса.

В своей практике я тоже пришел к идее создания велосипеда собственной простой версии BDD framework'а, который бы учитывал наблюдения, которые я сделал при работе с MSpec. В следующей статье из цикла "BDD Clarified" (work is in progress) детали и использование этого фреймворка будут рассмотрены подробнее. А пока лишь реклама.

[Scenario]
public class when_calculating_user_attendance_variation : with_user_attendance_statistics_analyzer
{
    double revenueVariation;

    public when_calculating_user_attendance_variation()
    {
        IsA<ScenarioSpecification>();
        Given(user_attendance_statistics_analyzer);
        Given(() => user_sent_visits(
            new UserVisit(client, 1, new DateTime(2011, 7, 1), 10, 1, new Money(3.0m, Currency.USD)),
            new UserVisit(client, 1, new DateTime(2011, 7, 1), 10, 1, new Money(4.0m, Currency.USD)),
            new UserVisit(client, 2, new DateTime(2011, 8, 1), 10, 1, new Money(10.0m, Currency.USD)),
            new UserVisit(client, 3, new DateTime(2011, 9, 1), 10, 2, new Money(4.0m, Currency.USD))));
        Given(() => analyzer.LoadUserStatistics(client));
        When(() => userCountVariation = analyzer.CalculateUserCountVariation(new DateTime(2011, 8, 1)));
    }

    [Then]
    public void variation_should_be_calculated_upon_total_count_of_all_users_of_subsequent_statistics_snapshots()
    {
        // (10USD - 7 USD)/7USD
        userCountVariation .Should().BeApproximately(0.4285, 0.0001);
    }
}

Resources

Behavior driven development:

BDD frameworks:

MSpec - Machine.Specifications is a Context/Specification framework geared towards removing language noise and simplifying tests. How to MSpec?
SpecFlow - binding business requirements to .Net code. Getting started.
NBehave is a framework for defining and executing application requirement goals.
NSpec is a BDD framework for .NET of the xSpec (context/specification) flavor. NSpec is intended to be used to drive development through specifying behavior at the unit level. NSpec is heavily inspired by RSpec and built upon the NUnit assertion library.

NHibernate: mapping class hierarchy

2011-05-23T00:51:00.002+03:00

Эта статья погрузит Вас в тонкие материи работы с 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 конструкции.

Исходная задача

Object model

Предметной областью является интернет-магазин, который выполняет заказы по созданию эксклюзивных альбомов и отправке их заказчику. Задача состоит в необходимости отслеживания событий, которые произошли с альбомом в процессе его обработки и отправки. Сущность Album обладает понятием статуса (Created, Prepared, Cancelled, ...), однако исключительно статуса недостаточно для описания жизненного цикла заказа. Некоторые значимые события могут не переводить заказ в новый статус. Помимо этого с каждым событием потенциально могут быть ассоциированы некоторые данные, специфичные именно для этого события. Например, для события отмены заказа (cancellation) важно знать кем был отменен заказ (WhoCancels), и какая причина. Если произошла ошибка, то важно знать описание ошибки, и где она произошла. В итоге приходим к такой объектной модели.

Данными, общими для всех событий, являются тип события (Type), время его возникновения (Timestamp), статус (AlbumStatus), в который это событие перевело или не перевело заказ. Некоторые события, такие как failure, cancellation, submit, содержат дополнительные данные. Другие события не содержат дополнительных данных, однако в объектной модели мы хотим представить их как отдельные классы, вместо того чтобы использовать базовый. Сущность Album имеет две ассоциации с событиями. Первая - это Events, то есть набор всех событий, произошедших с этим заказом, второй - LastEvent, то есть ссылка на последнее событие. Событие в свою очередь ссылается на заказ, к которому оно относится. То есть получается bidirectional association.

Relational model

Схема базы данных в свою очередь выглядит так.

С точки зрения БД, иерархия смоделирована в виде таблицы AlbumEvent, которая содержит данные, общие для всех событий. Данные расширенных событий (failure, cancellation, creation) помимо таблицы album_event содержатся в дополнительных таблицах (AlbumEventCancel, AlbumEventFail), которые связаны с AlbumEvent 1:1 по первичному ключу. Связи между Album и AlbumEvent представлена при помощи внешних ключей AlbumID и LastEventID.

Table-per-hierarchy

Стиль table-per-hierarchy состоит в том, что вся иерархия классов отображается на одну таблицу базы данных. Схема этой таблицы покрывает всё разнообразие данных всех классов иерархии. В нашем случае это могло бы выглядеть так.

Для того, чтобы отличить какому классу в иерархии соответствует та или иная строка, NHibernate'у необходимо указать так называемый discriminator value. В нашем случае - это Event type. Вот как бы выглядел mapping в table-per-hierarchy стиле.

public class AlbumEventMap : ClassMap<AlbumEventBase>
{
    public AlbumEventMap()
    {
        Table("AlbumEvent");

        Id(e => e.ID).Column("EventID").GeneratedBy.Native();
        Map(e => e.AlbumStatus).Not.Nullable().Length(32);
        Map(e => e.Timestamp).Not.Nullable();

        // tell NHibernate to use value from EventType column as a discriminator 
        DiscriminateSubClassesOnColumn("EventType");
    }
}

// usage of SubclassMap
public class FailedAlbumEventMap : SubclassMap<FailedAlbumEvent>
{
    public FailedAlbumEventMap()
    {
        // if EventType column has value FAIL, then map database row to FailedAlbumEvent class
        DiscriminatorValue("FAIL");

        // map additional properties
        // NOTE: all additional columns should be marked as nullable
        Map(e => e.Reason).Nullable().Length(40);
        Map(e => e.Origin).Nullable().Length(40);
        Map(e => e.Details).AsUnicodeString().Nullable().Length(1024);
    }
}

public class PreparedAlbumEventMap : SubclassMap<PreparedAlbumEvent>
{
    public PreparedAlbumEventMap()
    {
        DiscriminatorValue("PREPARED");
        // no additional properties to map
    }
}

Минус в том, что колонки, которые представляют дополнительные данные, должны быть nullable, даже если это и не соответсвует бизнес ограничениям. Это довольно неприятно. Помимо этого, таблица будет скорее всего полузаполненной, снова же из-за null значений. Из плюсов, это то, что данные находятся в одной таблице, а значит выполнение запросов будет быстрым.

Я бы использовал этот стиль только в том случае, если количество различных данных в иерархии довольно мало по отношению к количеству общих данных. Если это не так, то стоит рассмотреть другой вариант - table-per-subclass.

Table-per-subclass

Каждый класс в иерархии отображается на отдельную таблицу. То есть, если бы в нашей иерархии были только классы: CancelledAlbumEvent, FailedAlbumEvent, CreatedAlbumEvent, а в базе данных - таблицы: AlbumEvent, AlbumEventCancel, AlbumEventFail, AlbumEventSubmit, то можно было бы смело заявить, что это стиль table-per-subclass.

Mapping по сравнению с предыдущим сценарием отличается не сильно. В данном случае не нужно указывать discriminator, так как таблицы БД сами по себе являются теми отличительными значениями, которые нужны NHibernate'у.

public class AlbumEventMap : ClassMap<AlbumEventBase>
{
    public AlbumEventMap()
    {
        Table("AlbumEvent");
        
        Id(e => e.ID).Column("EventID").GeneratedBy.Native();
        Map(e => e.AlbumStatus).Not.Nullable().Length(32);
        Map(e => e.Timestamp).Not.Nullable();

        // no discriminator column
    }
}

// use SubclassMap once again
public class FailedAlbumEventMap : SubclassMap<FailedAlbumEvent>
{
    public FailedAlbumEventMap()
    {
        Table("AlbumEventFail");

        Map(e => e.Reason).Not.Nullable().Length(40);
        Map(e => e.Origin).Nullable().Length(40);
        Map(e => e.Details).AsUnicodeString().Not.Nullable().Length(1024);
    }
}

public class CreatedAlbumEventMap : SubclassMap<CreatedAlbumEvent>
{
    public CreatedAlbumEventMap()
    {
        Table("AlbumEventSubmit");
        Map(e => e.AlbumOrigin).Not.Nullable().Length(40);
    }
}

В классическом xml-based mapping используется конcтрукция joined-subclass.

Table-per-subclass, using a discriminator

Однако NHibernate не ограничивает нас, и дает возможность даже в случае table-per-subclass указать discriminator value. В нашем случае это выглядит довольно разумно, в качестве discriminator используем колонку EventType. Mapping несколько меняется, а в xml-based формате используется конструкция subclass + discriminator-value + join.

public class AlbumEventMap : ClassMap<AlbumEventBase>
{
    public AlbumEventMap()
    {
        Table("AlbumEvent");

        Id(e => e.ID).Column("EventID").GeneratedBy.Native();
        Map(e => e.AlbumStatus).Not.Nullable().Length(32);
        Map(e => e.Timestamp).Not.Nullable();

        DiscriminateSubClassesOnColumn("EventType");
    }
}

public class FailedAlbumEventMap : SubclassMap<FailedAlbumEvent>
{
    public FailedAlbumEventMap()
    {
        DiscriminatorValue("FAIL");
        Join("AlbumEventFail", j =>
        {
            j.KeyColumn("EventID");
            j.Map(e => e.Reason).Not.Nullable().Length(40);
            j.Map(e => e.Origin).Nullable().Length(40);
            j.Map(e => e.Details).AsUnicodeString().Not.Nullable().Length(1024);
        });
    }
}

Можно сказать, что "table-per-subclass, using discriminator" - это мост, который позволяет связать два стиля: table-per-subclass и table-per-hierarchy. Так как table-per-hierarchy основан на использовании discriminator value, то table-per-subclass тоже должен поддерживать эту опцию.

2-in-1: table-per-subclass + table-per-hierarchy

Соединим два стиля, изложенных выше, вместе и применим их для решения нашей задачи. Простые классы событий будут отображены на таблицу album_event в стиле table-per-hierarchy, события же с дополнительными данными - на собственные таблицы в стиле table-per-subclass.

// base class mapping
public class AlbumEventMap : ClassMap<AlbumEventBase>
{
    public AlbumEventMap()
    {
        Table("AlbumEvent");

        Id(e => e.ID).Column("EventID").GeneratedBy.Native();
        Map(e => e.AlbumStatus).Not.Nullable().Length(32);
        Map(e => e.Timestamp).Not.Nullable();

        DiscriminateSubClassesOnColumn("EventType")
          
        // NOTE: this cannot be done, we've already used EventType as a discriminator column
        // NOTE: mapping the same column twice will cause update conflicts
        Map(e => e.Type).Column("EventType").Length(40);

    }
}

// simple event w/o additional data
// map it in a table-per-hierarchy style
public class PreparedAlbumEventMap : SubclassMap<PreparedAlbumEvent>
{
    public PreparedAlbumEventMap()
    {
        DiscriminatorValue("PREPARED");
    }
}

// event with custom data
// use table-per-subclass, using discriminator
public class CancelledAlbumEventMap : SubclassMap<CancelledAlbumEvent>
{
    public CancelledAlbumEventMap()
    {
        DiscriminatorValue("CANCEL");
        Join("AlbumEventCancel", j =>
        {
            j.KeyColumn("EventID");
            j.Map(e => e.WhoCancels).Not.Nullable().Length(40);
            j.Map(e => e.Comment).AsUnicodeString().Nullable().Length(1024);
        });
    }
}

Formula as a discriminator

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

Корень проблемы лежит в том, что если дважды отобразить одну и ту же колонку таблицы БД (как свойство сущности и как discriminator value), то могут возникнуть конфликты обновления, и NHibernate не сможет корректно разрешить, что именно использовать в качестве значения для этой колонки. Одно из решений - пометить discriminator как read-only.

...
<property name = "Type" column = "EventType" />
<discriminator column = "EventType" insert = "false" />
...

В отличии от xml-based syntax, fluent API не позволяет установить значение "insert = false". В качестве альтернативного варианта, можно указать формулу для discriminator value, а не фиксированную колонку.

Map(e => e.Type).Column("EventType").Length(40);
DiscriminateSubClassesOnColumn("").Formula("EventType");

В качестве формулы допускается любой валидный sql.

Map(e => e.Type).Column("EventType").Length(40);
DiscriminateSubClassesOnColumn("")
    .Formula("case when LEFT(EventType, 8) = 'Contract' then 'Contract' else EventType end");

Mapping against interface

При наличии иерархии AlbumEventBase : IAlbumEvent, возникает резонный вопрос почему таблица "album_event" отображается на базовый класс AlbumEventBase вместо интерфейса IAlbumEvent. Ведь другие классы ссылаются на интерфейс, а не на базовый класс. Базовый класс - детали реализации, исключительно для удобства, его могло бы и не быть. Чтож, попробуем переписать меппинг для интерфейса вместо базового класса.

public interface IAlbumEvent
{
    int ID { get; }
    EventType Type { get; }
    AlbumStatus Status { get; }
    Album Album { get; }
    DateTime Timestamp { get; }

    void Raise(Album album);
}

// change AlbumEventBase to IAlbumEvent
public class AlbumEventMap : ClassMap<IAlbumEvent>
//public class AlbumEventMap : ClassMap<AlbumEventBase>
{
    // the rest of the mapping is the same
}

NHibernate скажет:

NHibernate.PropertyNotFoundException: Could not find a setter for property 'ID' in class 'Events.IAlbumEvent'

Если модель допускает поднятие setter'ов на уровне интерфейса, то тогда все хоккей. Если же, нет, то тогда можно попытаться указать использовать backing field в качестве access strategy, чтобы NHibernate искал field, а не property setter.

Id(e => e.ID).Column("EventID")
    .GeneratedBy.Native()
    .Access.ReadOnlyPropertyThroughLowerCaseField(Prefix.Underscore);

И теперь:

NHibernate.PropertyNotFoundException: NHibernate.PropertyNotFoundException: Could not find field '_id' in class 'Events.IAlbumEvent'

Несмотря на то, что NHibernate больше не ищет property setter, а ищет backing field, однако ищет он его по-прежнему в интерфейсе, а не в базовом классе. Здесь обсуждается подобная проблема. Остается либо поднять property setter на уровень интерфейса, либо описывать меппинг по отношению к базовому классу. Однако это привносит другую проблему: можно ли будет использовать IAlbumEvent, если для него не описан меппинг? Ответ на этот вопрос: implicit polymorphism.

Implicit polymorphism

В качестве описания что такое implicit polymorphism, можно процитировать эту статью.

Implicit polymorphism means that instances of the class will be returned by a query that names any superclass or implemented interface or the class and that instances of any subclass of the class will be returned by a query that names the class itself. For most purposes the default, polymorphism=”implicit”, is appropriate.

А теперь попроще. Если запрос описан в терминах базового класса, или интерфейса, то помимо экземпляров этого класса запрос вернет экземпляры всех его подклассов, для которых описан меппинг.

Для нашего примера это значит, что нет необходимости явно описывать меппинг по отношению к интерфейсу IAlbumEvent, более того, используя интерфейс к примеру в ассоциации ISet<IAlbumEvent>, мы делаем такую коллекцию полиморфной, то есть результатом загрузки такой коллекции будет вся наша иерархия классов событий. Вот как будет выглядеть меппинг класса Album.

public class Album
{
    // associations are expressed in terms of IAlbumEvent, not AlbumEventBase
    public virtual IEnumerable<IAlbumEvent> Events { get; }
    public virtual IAlbumEvent LastEvent { get; private set; }
}

public class AlbumMap : ClassMap<Album>
{
    // note, explicit specification of AlbumEventBase as a type-parameter
    o.HasMany<AlbumEventBase>(o => o.Events).AsSet()
        .Inverse().Cascade.AllDeleteOrphan()
        .KeyColumn("AlbumID")
        .Access.ReadOnlyPropertyThroughCamelCaseField(Prefix.Underscore);
    
    o.References<AlbumEventBase>(o => o.LastEvent)
        .Nullable().Fetch.Join()
        .ForeignKey("FK_Album_Album_event_LastEventID");
}

И последний штрих, для того, чтобы все это работало. Нужно явно указать AlbumEventBase в качестве типа-параметра в конструкции o.HasMany<AlbumEventBase>(o => o.Events), иначе будет такая ошибка.

NHibernate.MappingException: Association references unmapped class: Events.IAlbumEvent.

How to get everything from DB?

Один интересный побочный эффект применения "implicit polymorphism". Каков будет результат выполнения этого запроса:

Session.Query<object>().ToList();

Да-да, вот так просто можно вытянуть всю базу данных. Хотя врядли это Вам понадобится. :)

Result sql query

Ну и сейчас наверное самое интересное, особенно для тех, кого беспокоит как будет выглядеть конечный sql запрос и его производительность. А это на самом деле не может не беспокоить, потому что если на проекте есть DBA, то он врядли будет рад километровым запросам с 32-мя уровнями вложенных select'ов, и рано или поздно он к Вам придет.

Итак, сделаем запрос на получение всех заказов вместе с его последним событием.

Session.Query<Album>().ToList();

И вот, что мы имеем на выходе.

SELECT
        album0_.AlbumID as AlbumID9_3_,
        album0_.AlbumStatusCode as AlbumSta4_9_3_,
        -- and more album related columns

        client1_.ClientID as ClientID0_0_,
        -- and more client related columns 

        -- all event related columns
        albumevent2_.EventID as EventID3_1_,
        albumevent2_.AlbumStatus as AlbumSta2_3_1_,
        albumevent2_.Timestamp as Timestamp3_1_,
        albumevent2_.EventType as EventType3_1_,
        albumevent2_.AlbumID as AlbumID3_1_,
        albumevent2_1_.WhoCancels as Actor4_1_,
        albumevent2_1_.Comment as Comment4_1_,
        albumevent2_2_.Reason as Reason5_1_,
        albumevent2_2_.Origin as Origin5_1_,
        albumevent2_2_.Details as Details5_1_,
        albumevent2_4_.AlbumOrigin as AlbumOri2_7_1_,
        case 
            when LEFT(albumevent2_.EventType, 8) = 'Contract' 
            then 'Contract' 
            else albumevent2_.EventType 
        end as clazz_1_
    FROM [Album] album0_ inner join Client client1_ 
        on album0_.ClientID=client1_.ClientID 
    left outer join
        AlbumEvent albumevent2_ 
            on album0_.LastEventID=albumevent2_.EventID 
    left outer join
        AlbumEventCancel albumevent2_1_ 
            on albumevent2_.EventID=albumevent2_1_.EventID 
    left outer join
        AlbumEventFail albumevent2_2_ 
            on albumevent2_.EventID=albumevent2_2_.EventID 
    left outer join
        AlbumEventCreated albumevent2_4_ 
            on albumevent2_.EventID=albumevent2_4_.EventID 
    WHERE
        album0_.AlbumID=@p0;

И здесь NHibernate потрясает нас чистотой запроса. На самом деле запрос близок к написанному человеком, и отличается разве что именованием.

Лирика

И напоследок, небольшое лирическое отступление на тему возможностей NHibernate.

NHibernate - мощная технология. Но чтобы овладеть ёё возможностями и заставить её работать, нужны труд и терпение, нужно осознать идею и вникнуть в детали. Поверхностных знаний недостаточно, и книжка "NHibernate за 12 часов" - тут не поможет. Да, высокий порог вхождения, но в этом в то же время и прелесть. Тем больше вероятность, что код будет писаться более опытными разработчиками, и тем меньше вероятность появления косяков.

NHibernate - как хороший автомобиль, на плохом бензине даже не заведется!

DI/IoC container lifestyles

2011-05-06T03:23:00.001+03:00

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

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

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

What is lifestyle?

В рамках разрешения зависимостей контейнер компонент должен решать задачи управления жизненным циклом компонент (создание, использование и освобождение компонента). При регистрации компонента в контейнере указывается lifestyle политика.

container.Register(Component
    .For<ISimpleService>()
    .ImplementedBy<SimpleServiceImpl>()
    .LifeStyle.Singleton;

container.Register(Component
    .For<ICompositeService>()
    .ImplementedBy<CompositeServiceImpl>()
    .LifeStyle.Transient;

Lifestyle политика определяет границы разделения, повторного использования компонента и времени жизни компонента. То есть указывая lifestyle, мы даем возможность контейнеру получить ответы на следущие вопросы:

Каким экземпляром компонента разрешать зависимость?
Нужно ли создавать новый компонент всякий раз, чтобы разрешить зависимость, либо использовать для этого ранее созданные экземпляры?
Каковы границы повторного использования ранее созданных компонент?
Когда ранее созданные компоненты становятся не пригодными для разрешения новых зависимостей?
Должен или компонент освобождать (release) созданные ранее компоненты? В какой момент времени нужно это делать?

В контексте обсуждения lifestyle'ов неважно в какой форме контейнер разрешает зависимость. Различие лишь в том, кто иницирует процесс разрешения и инвертирован ли этот процесс.

direct request, приложение запросило у контейнера предоставить ему зависимость.
dependency injection, контейнер сам предоставил зависимость компоненту.

Lifestyle types

Опишем наиболее общие типы lifestyle'ов, которые можно встретить во разных реализациях DI/IoC контейнеров.

Transient

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

[Test]
public void Given_transient_dependency_should_resolve_new_instance_of_component_for_any_request()
{
    var container = new WindsorContainer();
    container.Register(Component
        .For<ISimpleService>()
        .ImplementedBy<SimpleServiceImpl>()
        .LifeStyle.Transient);
            
    var instance1 = container.Resolve<ISimpleService>();
    var instance2 = container.Resolve<ISimpleService>();

    // verify instances are different
    Assert.IsFalse(ReferenceEquals(instance1, instance2));
}

Transient политика не определяет границу времени жизни компонента. Освобождение компонента зависит от режима отслеживания контейнером созданных компонентов. Если контейнер отслеживает и хранит ссылки на созданные им компоненты, то они освобождаются при уничтожении контейнера. В противном случае, приложение явно управляет временем жизни нужной ему зависимости, вызывая Dispose() в нужный момент времени.

Важно отметить, что реализация того, как и когда освобождаются transient компоненты, может варьироваться для разных реализаций DI/IoC контейнеров. К примеру, Autofac отслеживает все созданные transient компоненты, которые являются IDisposable, и освобождает их только при уничтожении самого контейнера компонент. Это значит, что если у вас в приложении есть контейнер компонент, время жизни которого совпадает с временем жизни приложения (к примеру, Windows service, при старте которого создается контейнер, и уничтожается только при останове сервиса), и вы запрашиваете transient зависимости, которые являются IDisposable, то такие зависимости останутся в памяти до завершения работы приложения, то есть возможны memory leaks. У Nicholas Blumhardt, разработчика Autofac, есть отличный пост на тему управления временем жизни компонент в Autofac, в частности он показывает, что нужно делать, чтобы избегать таких ситуаций.

Singleton

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

[Test]
public void Given_singleton_dependency_should_use_same_component_instance_throughout_container_lifetime()
{
    //setup component and dependent component
    var container = new WindsorContainer();
    container.Register(Component
        .For<ISimpleService>()
        .ImplementedBy<SimpleServiceImpl>()
        .LifeStyle.Singleton);
    container.Register(Component
        .For<ICompositeService>()
        .ImplementedBy<CompositeService>()
        .LifeStyle.Singleton);
            
    var simpleInstance1 = container.Resolve<ISimpleService>();
    var simpleInstance2 = container.Resolve<ISimpleService>();
    var compositeInstance = container.Resolve<ICompositeService>();

    // verify container returns same instances when directly asked
    Assert.AreEqual(simpleInstance1, simpleInstance2);
    // verify container uses the very same instance with dependency injection
    Assert.AreEqual(simpleInstance1, compositeInstance.SimpleService);
}

Per thread

Этот lifestyle похож на singleton lifestyle, c тем лишь отличием, что контекст повторного использования компонент ограничен рамками отдельного потока, а не рамками жизни контейнера. Для разных потоков будут созданы различные экземпляры. Зависимость также является разделяемой.

[Test]
public void Given_per_thread_dependency_should_reuse_same_component_within_same_thread()
{
    var container = new WindsorContainer();
    container.Register(Component
        .For<ISimpleService>()
        .ImplementedBy<SimpleServiceImpl>()
        .LifeStyle.PerThread);

    var instanceFromThreadA = GetInstanceResolvedInThreadA(container);
    var instanceFromThreadB = GetInstanceResolvedInThreadB(container);
    // verify instances resolved in different threads are different
    Assert.AreNotEqual(instanceFromThreadA, instanceFromThreadB);

    var instanceFromSameThread1 = container.Resolve<ISimpleService>();
    var instanceFromSameThread2 = container.Resolve<ISimpleService>();
    // verify instances resolved in same threads are same
    Assert.AreEqual(instanceFromSameThread1, instanceFromSameThread2);
}

Per Web Request

Аналогичен per thread, c тем лишь отличием, что границами времени жизни и разделения компонент является отдельный web request (имеется ввиду ASP.NET Http Request).

Component tracking and release

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

Autofac позволяет указать контейнеру не освобождать IDisposable компоненты, подразумевая, что это становится обязанностью приложения. Хотя контейнер по-прежнему продолжает отслеживать разделяемые компоненты для их дальнейшего использования (singleton, per thread, per web request). Однако контейнеру более не надо отслеживать IDisposable transient компоненты.

[Test]
public void Autofac_gives_ability_to_configure_container_not_to_release_component()
{
    var containerBuilder = new ContainerBuilder();
  
    // let application to manage component disposal
    containerBuilder
        .RegisterType<SimpleServiceImpl>()
        .As<ISimpleService>()
        .ExternallyOwned();
}

Castle.Windsor предоставляет похожую функциональность при помощи понятия release policy. Однако по сравнению с Autofac в Castle.Windsor эта политика не может быть применена к отдельному компоненту, а лишь ко всему контейнеру в целом.

[Test]
public void Castle_windsor_gives_ability_to_configure_container_not_to_track_components()
{
    var container = new WindsorContainer();
   
    // do not track and dispose transient components
    // let application to manage component disposal
    container.Kernel.ReleasePolicy = new NoTrackingReleasePolicy();
}

Lifestyle types comparison in Castle.Windsor and Autofac

Сравним lifestyle политики, которые доступны в Castle.Windsor и Autofac.

Lifestyle policy	Castle.Windsor	Autofac
Transient	Yes	Yes
Singleton	Yes	Yes
Per lifetime scope	No	Yes
Per Thread	Yes	No
Per Web Request	Yes	No
Pooled	Yes	No
Custom lifestyle policy	Yes	No

Набор out-of-the-box lifestyle политик в Castle.Windsor несомненно больше, чем в Autofac, также в Castle.Windsor есть возможность создать собственную реализацию lifestyle, реализовав ILifestyleManager интерфейс. Однако большинство функциональных возможностей out-of-the-box lifestyle политик, доступных в Castle.Windsor, с легкостью можно получить в Autofac при помощи одной лишь "per lifetime scope" политики.

Например, per thread поведение можно получить следующим образом.

void ThreadStart()
{
   using (var threadLifetime = container.BeginLifetimeScope())
   {
      var thisThreadsInstance = threadLifetime.Resolve<MyThreadScopedComponent>();
   }
}

Аналогично можно получить поведение per web request, просто открыв lifetime scope в начала web request'а (HttpApplication.BeginRequest), и закрыв при завершении (HttpApplication.EndRequest).

Далее более детально посмотрим на "per lifetime scope" lifestyle политику.

"Per lifetime scope" lifestyle

Ранее описанные политики имеют одну общую черту: границы жизненного цикла и разделения компонент предопределены и являются внешними по отношению к приложению факторами. Per thread ограничен рамками потока, per web request - рамками http запроса, singleton - рамками контейнера. Было бы неплохо, если бы приложение могло cамо явно задавать рамки повторного использования компонент. И это как раз то, чем является "Per lifetime scope". Короче говоря, "per lifetime scope" политика позволяет явно обозначить unit of work в приложении.

К примеру, если приложение оперирует обработкой заказов, то имеет смысл определить такие unit of work, как client processing, order processing.

[Test]
public void Should_be_able_to_create_two_nested_lifetime_scopes()
{
    var containerBuilder = new ContainerBuilder();
    containerBuilder
        .RegisterType<SimpleServiceImpl>()
        .As<ISimpleService>()
        .InstancePerMatchingLifetimeScope("client");
    containerBuilder
        .RegisterType<CompositeService>()
        .As<ICompositeService>()
        .InstancePerMatchingLifetimeScope("order");

    using (var container = containerBuilder.Build())
    {
        Client client= GetClient();
        // begin single client processing and open lifetime scope
        using(var clientProcessingScope = container.BeginLifetimeScope("client"))
        {
            // create and use client-specific service
            var simpleService = clientProcessingScope.Resolve<ISimpleService>();
            //process orders of the client
            foreach (var order in client.Orders)
            {
                //begin single order processing, and open lifetime scope
                using (var orderProcessingScope = container.BeginLifetimeScope("order"))
                {
                    // create order-specific service, which uses service from client processing scope
                    var compositeService = orderProcessingScope.Resolve<ICompositeService>();
                    var clientSpecificServiceReferenced = compositeService.SimpleService;

                    // destroy all order-specific service at the end of scope
                }
            }

            // destroy all client-specific service at the end of scope
        }
    }
}

Отличительная черта и главная ценность "per lifetime scope" lifestyle по сравнению с другими политиками, это то, что рамками повторного использования компонент (lifetime scope) управляет приложение. Это дает дополнительную гибкость в выборе нужного lifetime scope, и не быть привязанными к готовым lifestyle'ам (per thread, per web request).

Implementation of "per lifetime scope" lifestyle for Castle.Windsor

Попытаемся восполнить отсутствие "per lifetime scope" lifestyle политики в Castle.Windsor и реализуем ее, используя ILifestyleManager extension point. В качеcтве вдохновения используем уже готовый lifestyle из Autofac.

Полная версия проекта (.net4, vs 2010) и исходный код этого решения выложен на github.

Поведение

Основные use case, которые хотим покрыть таковы.

Запросить компонент дважды в рамках открытого lifetime scope, и убедиться, что экземпляры идентичны.

[Test]
public void When_resolving_same_service_in_same_scope_several_times_should_return_the_same_component()
{
    var container = new WindsorContainer();
    container.Register(Component
        .For<ISimpleService>()
        .ImplementedBy<SimpleServiceImpl>()
        .LifeStyle.Custom<PerLifetimeScopeLifestyle<string>>());

    using (new LifetimeScope<string>())
    {
        var service1 = container.Resolve<ISimpleService>();
        var service2 = container.Resolve<ISimpleService>();
        Assert.AreEqual(service1, service2);
    }
}

Запросить один и тот же компонент в разных lifetime scope'ах, и убедиться что экземпляры разные.

[Test]
public void When_resolving_same_service_in_different_scope_several_times_should_return_different_components()
{
    var container = new WindsorContainer();
    container.Register(Component
        .For<ISimpleService>()
        .ImplementedBy<SimpleServiceImpl>()
        .LifeStyle.Custom<PerLifetimeScopeLifestyle<string>>());

    ISimpleService service1, service2;
    using (new LifetimeScope<string>())
    {
        service1 = container.Resolve<ISimpleService>();
    }
    using (new LifetimeScope<string>())
    {
        service2 = container.Resolve<ISimpleService>();
    }

    Assert.AreNotEqual(service1, service2);
}

Во вложенном lifetime scope'е разрешить компонент, который имеет зависимость на компонент, который доступен во внешнем lifetime scope.

[Test]
public void If_service_in_scope_has_dependecy_to_service_which_is_in_outer_scope_container_should_wire_it()
{
    var container = new WindsorContainer();
    container.Register(Component
        .For<ISimpleService>()
        .ImplementedBy<SimpleServiceImpl>()
        .LifeStyle.Custom<PerLifetimeScopeLifestyle<int>>());
    container.Register(Component
        .For<ICompositeService>()
        .ImplementedBy<CompositeServiceImpl>()
        .LifeStyle.Custom<PerLifetimeScopeLifestyle<string>>());

    using (new LifetimeScope<int>())
    {
        var simpleService = container.Resolve<ISimpleService>();
        using (new LifetimeScope<string>())
        {
            var compositeService = container.Resolve<ICompositeService>();
            Assert.AreEqual(simpleService, compositeService.SimpleService);
        }
    }
}

Объявление границ lifetime scope (unit of work)

Итак, начнем с самого простого. Приложению нужно каким-то образом обозначить начало и конец lifetime scope, то есть обозначить границы unit of work.

public class LifetimeScope<TContext> : IDisposable
{
    public LifetimeScope()
    {
        LifetimeScopeStore.Get>TContext>().OpenScope();
    }

    public void Dispose()
    {
        LifetimeScopeStore.Get<TContext>().CloseScope();
    }
}

Механизм хранения созданных компонент

Далее, необходимо определить, где будут хранится экземпляры компонент с "per lifetime scope" lifestyle, созданные контейнером. Требования к механизму хранения следующие.

Нужно обеспечить, чтобы компоненты, созданные однажды, были доступны в любом месте ниже по call hierarchy. Допустим, имеется цепочка вызовов методов.
Нужно обеспечить, чтобы компоненты были доступны в дочерних потоках.

Для этого нам подойдет такое хранилище как CallContext, подробнее здесь.

При использовании CallContext, можно столкнутся с проблемой, что данные, сохраненные в одном потоке, становятся недоступными в дочернем, то есть не удовлетворяется требование №2. Для того чтобы побороть эту проблему, нужно пометить класс, экземпляры которого будут хранится в Call context, маркерным интерфейсом ILogicalThreadAffinative.

private class LogicalThreadAffinativeDictionary : Dictionary<object, object>, ILogicalThreadAffinative
{ }

Реализация ILifestyleManager

ILifestyleManager - extension point Castle Windsor'а для создания собственных lifestyle политик. Наша реализация PerLifetimeScopeLifestyle при разрешении зависимости будет создавать новый экземпляр зависимости и сохранять его в слоте данных CallContext. Если компонент ранее был создан, то будет использовать его повторно. В случае явного запроса на освобождение компонента, будет удалять его из слота данных CallContext'а.

public class PerLifetimeScopeLifestyle>TContext> : AbstractLifestyleManager
{
    public class ComponentInstance : IDisposable { ... }
        
    public override void Dispose()
    { }

    public override bool Release(object instance)
    {
        LifetimeScopeStore.Get<TContext>().TryRemove(this);
        return base.Release(instance);
    } 

    private bool ReleaseOnScopeExiting(object instance)
    {
        return base.Release(instance);
    }

    public override object Resolve(CreationContext context)
    {
        return LifetimeScopeStore.Get<TContext>()
            .GetOrAdd(this, lifestyleManager => new ComponentInstance(lifestyleManager, base.Resolve(context)))
            .Instance;
    }
}

Ограничения и недостатки решения

Недостатком является то, что Lifetime scope обязательно должен быть помечен неким тегом. В данном реализации тегом выступает тип TContext, используемый при создании класса LifetimeScope.

// this is supported
// lifetime scope is tagged with Client
using (new LifetimeScope<Client>())
{...}

// this is not supported
using (new LifetimeScope())
{...}

Source code hosted on github

Полная версия проекта (.net4, vs 2010) и исходный код этого решения выложен на github.

 $ git clone git://github.com/samoshkin/ContextualLifetimeScope.git

NHibernate session management

2011-04-29T17:22:00.002+03:00

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

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

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

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

Session/transaction scope

При изучении NHibernate, практически во всех примерах, которые показывают как работать с persistent сущностями, можно увидеть такой код.

using(var session = SessionFactory.OpenSession())
using(var transaction = session.BeginTransaction())
{
    //do some work, get all orders from DB for example
    
    transaction.Commit();
}

За время обучения NHibernate'у, этот код настолько отпечатывается в мозгу, что воспринимаешь его как нечто данное по-умолчанию, и не задумываешься, что это всего лишь один из возможных подходов к управлению уровнем гранулярности сессий/транзакций.

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

ISession - a scope of object identity

NHibernate ISession определяет scope of object identity. Выглядит весьма запутано. Для непосвященного человека это определение отнюдь не расшифровывает термин ISession, а лишь вводит еще один термин scope of object identity. Scope of object identity - это условия, при которых .NET identity объекта (ReferenceEquals(a, b)) эквивалетно database identity (a.Id == b.Id).

К примеру, в базе данных есть запись в таблице Order. Database identity определяется первичным ключом таблицы. То есть, если сравнивать две записи, то они будут считаться идентичными, если у них одинаковые значения первичного ключа (a.Id == b.Id). Между прочим, реляционная модель не разрешает наличие двух записей с одним и тем же значением первичного ключа.

Если рассматривать .NET application domain, то здесь в качестве object identity выступает адрес объекта в памяти. Если для двух объектов выполняется условие ReferenceEquals(a, b), то такие объекты будут считаться идентичными.

Далее, рассмотрим такой сценарий. Приложение делает два запроса на получение заказа с ID равным 100.

using(var session = SessionFactory.OpenSession())
using(var transaction = session.BeginTransaction())
{
    var a = session.Get<Order>(100);
    var b = session.Get<Order>(100);
}

В данном случае приложение оперирует двумя объектами a и b, которые представляют одну и ту же запись в базе данных. Так вот, scope of object identity определяет границы, в которых a будет идентично b (ReferenceEquals(a, b)). В коде выше это условие будет выполнятся, так как оба запроса находятся в рамках одного и того же object identity scope, который декларируется при помощи класса ISession.

Если бы запросы делались в разных сессиях, то условие идентичности a и b не выполнялось бы, несмотря на то, что оба объекта представляют одну и ту же запись в таблице базы данных.

using(var session = SessionFactory.OpenSession())
using(var transaction = session.BeginTransaction())
{
    var a = session.Get<Order>(100);
}

using(var session = SessionFactory.OpenSession())
using(var transaction = session.BeginTransaction())
{
    var b = session.Get<Order>(100);
}

Assert.IsFalse(ReferenceEquals(a, b));

Различают такие подходы к определению scope of object identity:

no identity scope - нет никаких гарантий, что если два раза сделан запрос на получение одной строки из БД, то приложение будет оперировать идентичными объектами.
transaction-scoped identity, условие идентичности гарантируется в рамках транзакции (имеется ввиду не database transaction).
process-scoped identity, условие идентичности гарантируется в рамках всего приложения, application domain, если быть конкретней.

В NHibernate реализована transaction-scoped identity, правильней даже сказать, user-defined scoped identity. Работа с сессией осуществляется при помощи классов ISessionFactory, ISession.

ITransaction - a scope of database transaction

Scope ITransaction'а полностью соответсвует транзакции на уровне БД. То есть, начало новой транзакции session.BeginTransaction() приводит к началу новой транзакции на уровне базы данных. Соответсвенно, transaction.Commit() и transaction.Rollback() завершают транзакцию на уровне БД, открытую ранее.

Так как работа с ITransaction приводит к открытию транзакции на уровне БД, то нужно стремится, чтобы scope ITransaction был настолько мал, насколько это действительно нужно. Длинные транзакции - это нечто, чего следует избегать, так как это приводит к удержанию блокировок и неэффективному разделению ресурсов. Обычно transaction scope соответсвует выполнению операции либо группы операций по взаимодействию с базой (выборка заказов, последовательная работа с балансом двух счетов).

Transaction scope отнюдь не должен соответвовать session scope. В учебных примерах, где выполняется одна или две операции - скорее да. Но в реальных приложениях session scope обычно шире чем transaction scope. В scope одной сессии может быть осуществлено несколько транзакций.

Введем еще одно понятие: Conversation или user transaction.

Conversation

Conversation, или user transaction - это некая единица работы с системой с точки зрения пользователя. Обычно она состоит из последовательности шагов, набора запросов к приложению, набора запросов по работе с БД. К примеру, это может быть процедура order placement, которая включает такие шаги: выбора единиц заказа, варианта доставки, варианта оплаты, и т.д. В рамках этих шагов приложению может быть необходимо осуществить N запросов к БД, и розумеется, в данном случае нельзя полагаться на database-level transaction для изоляции конкурентных conversation'ов.

Далее будут показаны различные варианты выбора уровня гранулярности session/transaction scope.

Level of session/transaction scope granularity

Session per request

Первый и самый простой вариант - это когда гранулярность transaction и session scope совпадают.

В данной ситуации нас не волнует понятие conversation, либо оно вообще не применимо. Зачастую этот подход применяется для обслуживания запросов приложения, например http request'a в ASP.NET приложении, либо запроса веб-сервиса, либо просто выполнение кода по взаимодействию с БД в консольном приложении.

Если в рамках session scope помимо взаимодействию с БД выполняется дополнительная работа, то ее длительность может стать неприемлимой для transaction scope, и мы прийдем к вариции session-per-request "1 session - N транзакций". Этот вариант наиболее ярко проявляется, если в рамках session scope, происходит несколько независимых запросов к БД, между которыми есть некие потенциально длительные вычисления (получение заказа, подсчет цен, сохранение цен вместе с измененным заказом).

Session per request with detached objects

В этой ситуации в рассмотрение входит понятие conversation. К примеру, пользователь делает запрос на получение первых 10 заказов, далее редактирует их, и потом делает запрос на обновление. Сколько времени займет редактирование - неизвестно. Вопрос: "Какой должен быть scope сессии?" Должен ли он охватывать всю user transaction, начиная с момента выборки ордеров, и заканчиваю их обновлением, либо же для каждого отдельного шага должен создаваться отдельный session scope?

В данном подходе применяется последний вариант. А для того, чтобы обеспечить возможность повторного использования сущностей, которые были получены на первом этапе (получение первых 10 заказов) во время второго этапа (обновление заказов), применяется понятие NHibernate'а "detached objects". Это значит, что объекты, полученные в рамках одного session scope покидают его, становясь "detached", и далее, прикрепляются к другому session scope. Такие "detached" объекты могут быть переданы в другой layer приложения, возможно даже в другой application domain, либо вообще за рамки системы, и более того, возвращены обратно позже (Silverlight UI layer).

Session per conversation

Этот подход противоположен предыдущему, то есть session scope соответствует conversation scope. В интервале между запросами к приложению, session отсоединяется от database connection при помощи операции session.Disconnect(). Таким образом, экземпляр IDbConnection может быть возвращен в connection pool и повторно использован для обслуживания другого запроса в то время, пока пользователь, скажем, редактирует заказы. На мой взгляд, этот подход находит применение в довольно экзотических случаях и редко. Я бы не рекомендовал его исопользование без видимых на то причин.

Ну а так как использовать database transaction для изоляции конкуретного доступа в рамках long-running conversation мы не можем, то в действие вступают механизмы optimistic locking'а. Хотя это уже тема для отдельной статьи.

Session management

Why do we need anything else?

Для задач управления сессиями/транзакциями используются классы ISessionFactory, ISession, ITransaction. Эти интерфейсы удобны, и можно было бы пользоваться ими напрямую. Однако, есть аргументы в пользу реализации некоторого слоя поверх этих интерфейсов, либо набора helper-class'ов, если слово "слой" звучит слишком серьезно. Вот некоторые из этих аргументов.

Клиенты data-access layer приложения не должны знать об использовании NHibernate.
Что касается меня, то я к этому отношусь довольно спокойно, и не вижу ничего криминального, если знания об использовании NHibernate вытекут наружу из data-access layer. Во-первых, скрыть полностью врятли удасться, во-вторых, это сложно, в-третьих, скорее всего ограничить себя и пожертвовать возможностью в полной мере использовать фичи NHibernate. Ну и самое главное: "А нужно ли это?". Подобный вопрос возникает, когда задаются целью скрыть знание о том, что данные сохраняются в БД, а не в файле к примеру. Нужно ответить на вопрос: "Насколько вероятно, что back-end storage поменяется с БД на файловую систему?". Скорее всего, 0.001%. Тоже самое касается механизма работы data-access layer. "Как часто меняется реализация persistence layer? Как часто переезжаем с dataset'ов на NHibernate, с NHibernate на data reader'ы?". На текущем проекте, к примеру, через 2 года после старта, переезжаем с Entity Framework на NHibernate. Не думаю, что стоит вкладывать усилия на скрытие этой информации. Изменения маловероятны. Более того, думаю, что цель ограничения масштаба возможных изменений все равно достигнута не будет.
Объект ISession может использоваться в месте отличном от того, где он был создан.
Обычно, ISession создается в одном месте, а использоваться может пятью методами ниже по call stack'у. В таком случае придется передавать объект ISession через все промежуточные компоненты, и засорять их ненужным знанием. Необходимо понятие текущей открытой сессии, которую можно получить в том месте, где она нужна, без необходимости ее передачи.
Вероятно использование Repository либо DAO, которым необходим объект ISessionFactory/ISession.
Применяются dependency injection практики. Было бы неплохо иметь возможность делать constructor injection текущей открытой сессии там, где она необходима (в том же Repository/DAO), и дать возможность контейнеру разрешить зависимости автоматически.

Session management helper classes

Вот что получилось в итоге сделать.

IPersistenceContext

Предоставляет доступ к текущей открытой сессии при помощи свойства CurrentSession, а также объектам ISessionFactory, с помощью которой была создана сессия, ну и configuration'у всего persistence layer'а.

public interface IPersistenceContext
{
    Configuration       Configuration { get; }
    ISessionFactory     SessionFactory { get; }
    ISession            CurrentSession { get; }
}

Предполагается, что можно сделать constructor injection IPersistenceContext в те классы, где необходимо взаимодействие с persistent слоем, к примеру EntityRepository. Также IPersistenceContext может быть с легкостью подменен на fake object в тестах.

public class EntityRepository<T> : IEntityRepository<T>
{
    //constructor injection of IPersistenceContext
    public EntityRepository(IPersistenceContext persistenceContext)
    {
        ...
    }

    public T Get(object id)
    {
        return _persistenceContext.CurrentSession.Get<T>(id);
    }
    ...
}

Implementation of IPersistentContext

Реализация PersistentContext принимает Configuration, и в ее обязанности входит управление жизненным циклом ISessionFactory, а также предоставление доступа к текушей открытой сессии. Наверное, здесь - это единственный интересный момент.

public class PersistenceContext : IPersistenceContext, IDisposable
{
    private readonly Configuration _configuration;
    private readonly ISessionFactory _sessionFactory;
 
    public PersistenceContext(Configuration configuration)
    {
        _configuration = configuration;
        _sessionFactory = _configuration.BuildSessionFactory();
    }

    public Configuration Configuration { get { return _configuration; }}
    public ISessionFactory SessionFactory { get { return _sessionFactory; } }

    public ISession CurrentSession
    {
        get
        {
            if (!CurrentSessionContext.HasBind(SessionFactory))
            {
                OnContextualSessionIsNotFound();
            }
            var contextualSession = SessionFactory.GetCurrentSession();
            if (contextualSession == null)
            {
                OnContextualSessionIsNotFound();
            }
            return contextualSession; 
        }
    }

    public void Dispose()
    {
     SessionFactory.Dispose();
    }

    private static void OnContextualSessionIsNotFound()
    {
        throw new InvalidOperationException("Ambient instance of contextual session is not found. Open the db session before.");
    }
}

Используется feature NHibernate'а под названием contextual session. Таким образом, все, что ожидает этот класс, это то, что текущая открытая сессия будет ассоциирована с неким контекстом и доступна через ISessionFactory.GetCurrentSession().

Использование CallSessionContext в качестве стратегии хранения текущей открытой сессии.

Доступны такие стратегии места хранения текущей сессии.

ManagedWebSessionContext, WebSessionContext, текущая сессия хранится в HttpContext.
CallSessionContext, текущая сессия хранится в CallContext.
ThreadStaticSessionContext, текущая сессия хранится в thread static.

Из различных вариантов выбора контекста сессии остановился на использовании call context. Call context предоставляет слоты, где можно сохранить объекты, которые будут доступны ниже по call stack, а также дочерним потокам. Более подробно o CallContext здесь. Из ограничений использования этого подхода, это то, что нельзя делать вложенные session scope, но думаю это и не надо.

Конфигурация выбора нужной реализации ICurrentSessionContext проста. Вот как это выглядит при использовании Fluent NHibernate.

Fluently.Configure().Database(MsSqlConfiguration.MsSql2005
    .ConnectionString("bar")
    .CurrentSessionContext(typeof(CallSessionContext).FullName))

Или с помощью классической конфигурации NHibernate:

var cfg = new Configuration();
cfg.Properties[Environment.ProxyFactoryFactoryClass] = typeof(ProxyFactoryFactory).AssemblyQualifiedName;
cfg.Properties[Environment.CurrentSessionContextClass] = typeof(CallSessionContext).FullName;

Демаркация unit of work'а

Последнее, что осталось сделать - это обозначить границы session scope, то есть наш unit of work. Просто создать новый ISession c помощью ISessionFactory.OpenSession() по-старинке недостаточно. Нужно еще связать созданную сессию с CurrentSessionContext.

public class DbSession : IDisposable
{
    private readonly ISessionFactory _sessionFactory;

    public DbSession(IPersistentContext persistentContext)
    {
        _sessionFactory = persistentContext.SessionFactory;
        CurrentSessionContext.Bind(_sessionFactory.OpenSession());
    }
 
    public void Dispose()
    {
        var session = CurrentSessionContext.Unbind(_sessionFactory);
        if (session != null && session.IsOpen)
        {
            try
            {
                if (session.Transaction != null && session.Transaction.IsActive)
                {
                    session.Transaction.Rollback();
                }
            }
            finally
            {
                session.Dispose();
            }
        }
    }
}

Основная обязанность класса это управление жизненным циклом сессии, привязывание/отвязывание текущей сессии от CurrentSessionContext. Класс не знает о выбранной стратегии реализации ICurrentSessionContext. Получается, что DbSession и PersistenceContext напрямую друг о друге ничего не знают, но знают куда положить и где забрать текущую сессию, вся коммуникация осуществляется через CurrentSessionContext.

Usability/testability

Имея такие сервисы как ISessionFactory, IPersistenceContext, IEntityRepository становится просто тестировать приложение, подменяя зависимости на fake в тестах. При использовании DI/IoC контейнера, благодаря использованию constructor injection, становится возможно зарегистрировать все сервисы в контейнере и дать ему возможность автоматически разрешить зависимости.

Вот как выглядит использование описанных выше коснтрукций в различных сценариях.


// this routine is usually executed only one per application run
// configure persistent layer and create session factory
Configuration configuration = ConfigurePersistenceLayer();
IPersistentContext persistentContext = new PersistentContext(configuration);

// somewhere in application
// new DbSession opens new NH ISession and attach to CurrentSessionContext
using (new DbSession(persistenceContext))
{
     // repository usage
     var orderRepository = new EntityRepository<Order>(persistenceContext);
     var order = orderRepository.Get(1);
        
     // usage of transaction with scope different from session scope
     using(var transaction = persistenceContext.CurrentSession.BeginTransaction())
     {
         // direct using of current session
         var allOrders = persistenceContext.CurrentSession.Query<Order>().ToList();
          
         transaction.Rollback();
     }

     // do not use current session, create new stateless session
     var statelessSession = persistenceContext.SessionFactory.OpenStatelessSession();
}

// direct using session out of DbSession scope through SessionFactory
var session = persistenceContext.SessionFactory.OpenSession();

Resources

To be continued...

В следующем посте, в качестве продолжения текущего, планирую рассказать о следующем.

Реализация паттерна Repository в контексте использования NHibernate.
Возможности формирования запросов в NHibernate, и адаптация этих возможностей для реализации Repository паттерна.

Mapping object hierarchies with AutoMapper

2011-04-08T06:04:00.003+03:00

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

Object model

Проблема отображения усложняется еще и тем, что нужно не просто отобразить одну плоскую сущность на другую, нужно отобразить иерархии сущностей из разных слоев приложения, которые конечно же отличаются друг от друга, иначе было бы не интересно. Смотрим диаграмму классов исходных сущностей (domain model).

В двух словах - описание модели. Есть сущность Album, которая представляет собой альбом с эксклюзивными фотографиями, который заказывается через интернет-магазин. Каждое событие, происходящее с альбомом в рамках его жизненного цикла, моделируется как сущность типа IAlbumEvent. Обычно каждое такое событие моделируется отдельным классом, который наследуется от IAlbumEvent + AlbumEventBase, однако есть и исключения. Эти дочерние классы содержат данные, специфичные для этого события, а также логику, скажем, для обновления статуса альбома.

С другой стороны есть иерархия сущностей, которая является целевой, и в которую необходимо переложить исходные сущности (data model). Эта модель в свою очередь 1:1 отображается на объекты базы данных при помощи ORM.

Последняя модель отличается от исходной по следующим параметрам:

Сущность моделируется в виде отдельного класса, только если есть специфичные данные. Таким образом, в этой модели нет таких классов как CreatedAlbumEvent, SentAlbumEvent, у которых нет собственных уникальных элементов данных.
Используются элементарные типы данных. Например, вместо Album используется только AlbumID, вместо enum EventType - строковое значение. Вместо DateTime снова же используется строковое значение.
Именование элементов данных.

А так как основная проблема при отображении - это отличия между исходной и целевой сущностями, то наше решение должно уметь справляться с описанными case'ами.

Custom solution

Как решается эта проблема в большинстве случаев? Пишется что-то в таком духе.

public class CustomMapper
{
    public AlbumEventTarget MapToDataRepresentation(IAlbumEvent albumEventSource)
    {
        AlbumEventTarget albumEvent;
        if(albumEventSource is AlbumFailedEvent)
        {
            albumEvent = MapFailureAlbumEvent(albumEventSource as FailureAlbumEvent);
        }
        else if(albumEventSource is ProcessingCancelledAlbumEvent)
        {
        albumEvent = MapCancellationAlbumEvent(albumEventSource as CancellationAlbumEvent);
        }
        else if(albumEventSource is RestartAlbumEvent)
        {
            albumEvent = MapReshipAlbumEvent(albumEventSource as RestartAlbumEvent);
        }
        else
        {
            albumEvent = new AlbumEventTarget();
            albumEvent.EventID = albumEventSource.EventID;
            albumEvent.EventType = albumEventSource.Type.ToString().ToUpper();
            albumEvent.AlbumStatus = albumEventSource.Status.ToString();
            albumEvent.Timestamp = albumEventSource.Timestamp.ToString("MM/dd/yyyy", CultureInfo.InvariantCulture);
        }
        return albumEvent;
    }
}

Рано или поздно механическое перекладывание данных из одной сущности в другую по крайней мере утомляет, особенно если сущности побольше и посложнее. Также, этот подход ведет к дублированию кода. К примеру, значение EventType отображается как строка в upper case. А если это system-wide правило, то нам врядли захочется везде дублировать эту логику. Частично проблему можно решить введением класса-конвертера.

public class EnumStringConverter
{
    private readonly Type _enumType;

    public EnumStringConverter(Type enumType)
    {
        _enumType = enumType;
    }

    public string ConvertEnumToString(object enumObject)
    {
        return enumObject.ToString().ToUpper();
    }

    public object ConvertStringToEnum(string value)
    {
        return Enum.Parse(_enumType, value, true);
    }
}

То же самое можно сделать и для преобразования даты в определенном формате (MM/dd/yyyy), а затем везде использовать эти конвертеры, однако рутина ручного перекладывания все еще утомительна, особенно когда сущности практически идентичны. Также, при ручном перекладывании высока вероятность ненамеренно ошибиться.

AutoMapper

Что такое AutoMapper и зачем он нужен?

A convention-based object-object mapper.

AutoMapper uses a fluent configuration API to define an object-object mapping strategy. AutoMapper uses a convention-based matching algorithm to match up source to destination values. Currently, AutoMapper is geared towards model projection scenarios to flatten complex object models to DTOs and other simple objects, whose design is better suited for serialization, communication, messaging, or simply an anti-corruption layer between the domain and application layer.

Object-object mapping - то, что нам нужно. Convention-based, fluent API - ну что ж, конфигурирование отображения обещает быть немногословным и читабельным. Ничего не сказано про меппинг иерархий сущностей - попробуем прикрутить.

Посмотрим как можно с его помощью отобразить сущность CreatedAlbumEvent на AlbumEventTarget.

    Mapper.CreateMap<EventType, string>().ConvertUsing<EnumStringConverterAdapter<EventType>>();
    Mapper.CreateMap<AlbumStatusEnum, string>().ConvertUsing<EnumStringConverterAdapter<AlbumStatusEnum>>();

    Mapper.CreateMap<CreatedAlbumEvent, AlbumEventTarget>()
        .ForMember(t => t.AlbumStatus, m => m.MapFrom(s => s.Status))
        .ForMember(t => t.EventType, m => m.MapFrom(s => s.Type));

Отображение отдельного элемента данных описывается при помощи кострукции ForMember только для тех элементов, чьё именование различается в исходной и целевой сущностях. Элементы с одинаковым именованием будут отображены автоматически (convention-based). Также указано, как отображать перечисления EventType, AlbumStatusEnum в значения строкового типа (custom type converters). Более того, однажды описав custom type converter, AutoMapper будет использовать его в любом другом отображении, в нашем случае, при отображении CreatedAlbumEvent в AlbumEventTarget. Таким образом, область действия custom type converter - application-wide scope. Если необходимо выборочное применение преобразования, используется такое понятие, как custom value resolver.

Custom value resolver

Предположим, что AlbumStatus перечисление в качестве исключения не нужно преобразовывать в upper case, а просто использовать метод ToString().

     Mapper.CreateMap<CreatedAlbumEvent, AlbumEventTarget>()
        .ForMember(t => t.AlbumStatus, m => m.ResolveUsing<SimpleEnumResolver>().FromMember(s => s.Status))
        .ForMember(t => t.EventType, m => m.MapFrom(s => s.Type));

В данном случае для отображения AlbumStatus применили custom value resolver. Конечно, отдельный класс для этих целей - это overhead. Было бы неплохо обойтись lambda выражением.

public class SimpleEnumResolver : ValueResolver<AlbumStatusEnum, string>
{
    protected override string ResolveCore(AlbumStatusEnum source)
    {
        return source.ToString();
    }
}

Custom value formatter

Value formatter - этот тот же type converter, только целевой тип - это всегда string. Применим его для отображения Timestamp элемента данных (DateTime в string).

mapping.ForMember(t => t.Timestamp, m => m.AddFormatter<DateTimeFormatter>())

где DateTimeFormatter опять же отдельный класс:

public class DateTimeFormatter : ValueFormatter<DateTime>
{
    protected override string FormatValueCore(DateTime value)
    {
        return value.ToString("MM/dd/yyyy", CultureInfo.InvariantCulture);
    }
}

Отображение иерархий сущностей

Пока что все просто. Попробуем отобразить сущности, входящие в иерархию. Хочется в результате иметь возможность использовать API нашего самописного CustomMapper, переключив его реализацию на использование AutoMapper'а. Ну или вообще отказаться от этого класса, главное чтобы API был выражен в терминах базовых сущностей из обеих иерархий: IAlbumEvent, AlbumEventTarget.

public class CustomMapper
{
    public AlbumEventTarget MapToDataRepresentation(IAlbumEvent albumEventSource)
    {
        return Mapper.Map<IAlbumEvent, AlbumEventTarget>(albumEventSource);
    }
}

В первом приближении конфигурация отображения выглядит так.

Mapper.CreateMap<IAlbumEvent, AlbumEventTarget>()
    .ForMember(t => t.AlbumStatus, m => m.ResolveUsing<SimpleEnumResolver>().FromMember(s => s.Status))
    .ForMember(t => t.EventType, m => m.MapFrom(s => s.Type))
    .Include<ProcessingCancelledAlbumEvent, AlbumEventCancelTarget>()
    .Include<FailedAlbumEvent, AlbumEventFailTarget>()
    .Include<CreatedAlbumEvent, AlbumEventTarget>()
    .Include<RestartAlbumEvent, AlbumEventRestartTarget>();

Mapper.CreateMap<ProcessingCancelledAlbumEvent, AlbumEventCancelTarget>();
Mapper.CreateMap<FailedAlbumEvent, AlbumEventFailTarget>();
Mapper.CreateMap<CreatedAlbumEvent, AlbumEventTarget>();
Mapper.CreateMap<ReshipAlbumEvent, AlbumEventReshipTarget>()
    .ForMember(s => s.AlbumID, m => m.MapFrom(s => s.SourceAlbum.AlbumID))
    .ForMember(s => s.RestartReasonName, m => m.MapFrom(s => s.Reason.Name));

Конфигурируется отображение базовых сущностей, далее идет описание отображения дочерних сущностей. А также, при помощи конструкции Include, отображение базовых сущностей теперь знает о существовании дочерних сущностей.

Однако, не все так гладко. Если попробовать отобразить ProcessingCancelledAlbumEvent в AlbumEventCancelTarget, то некоторые элементы данных в целевой сущности останутся неустановленными.

var albumEvent = new ProcessingCancelledAlbumEvent ("actor")
{
    EventID = 1,
    Status = AlbumStatusEnum.Created,
    Timestamp = new DateTime(2010, 1, 1),
    Type = EventType.Cancelled,
    Comment = "comment"
};
var target = (AlbumEventCancelTarget) Mapper.Map<IAlbumEvent, AlbumEventTarget>(albumEvent);

Итак, собственные элементы данных сущности ProcessingCancelledAlbumEvent такие как, Actor и Comment установлены. Отображение явно для них не конфигурировалось, однако ввиду одинакового именования элементов данных, они были отображены автоматически. Аналогичным образом были установлены свойства Tag, EventID, Timestamp, а вот Status и Type остались пустыми. То есть меппинг, описанный для связки IAlbumEvent-AlbumEventTarget ни коим образом не оказывает влияние на связку ProcessingCancelledAlbumEvent -AlbumEventCancelTarget. Приходим к решению повторять меппинг базовых элементов данных для каждой дочерней сущности.

Mapper.CreateMap<ProcessingCancelledAlbumEvent , AlbumEventCancelTarget>()
    .ForMember(t => t.AlbumStatus, m => m.ResolveUsing<SimpleEnumResolver>().FromMember(s => s.Status))
    .ForMember(t => t.EventType, m => m.MapFrom(s => s.Type))

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

public static class AlbumEventMappingExtensions
{
    public static IMappingExpression<TSource, TDestination> MapGenericAlbumEvent<TSource, TDestination>(
        this IMappingExpression<TSource, TDestination> mapping)
            where TSource : IAlbumEvent
            where TDestination : AlbumEventTarget
    {
        return mapping
            .ForMember(t => t.AlbumStatus, m => m.ResolveUsing<SimpleEnumResolver>().FromMember(s => s.Status))
            .ForMember(t => t.EventType, m => m.MapFrom(s => s.Type))
            .ForMember(t => t.Timestamp, m => m.AddFormatter<DateTimeFormatter>());
    }
}

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

Mapper.CreateMap<EventType, string>().ConvertUsing<EnumStringConverterAdapter<EventType>>();

Mapper.CreateMap<IAlbumEvent, AlbumEventTarget>()
    .MapGenericAlbumEventData()
    .Include<ProcessingCancelledAlbumEvent , AlbumEventCancelTarget>()
    .Include<FailedAlbumEvent, AlbumEventFailTarget>()
    .Include<CreatedAlbumEvent, AlbumEventTarget>()
    .Include<RestartAlbumEvent, AlbumEventRestartTarget>();

Mapper.CreateMap<ProcessingCancelledAlbumEvent , AlbumEventCancelTarget>().MapGenericAlbumEventData();
Mapper.CreateMap<FailedAlbumEvent, AlbumEventFailTarget>().MapGenericAlbumEventData();
Mapper.CreateMap<CreatedAlbumEvent, AlbumEventTarget>().MapGenericAlbumEventData();
Mapper.CreateMap<RestartAlbumEvent, AlbumEventReshipTarget>().MapGenericAlbumEventData()
    .ForMember(s => s.AlbumID, m => m.MapFrom(s => s.SourceAlbum.AlbumID))
    .ForMember(s => s.ReshipReasonID, m => m.MapFrom(s => s.Reason.ReasonID));

Polymorphic element types in collections

Особая ценность меппинга иерархии сущностей проявляется тогда, когда работа с сущностями происходит полиморфно. К примеру, у нас может быть коллекция сущностей IAlbumEvent[] (все события в жизненном цикле отдельного заказа), которую мы хотим отобразить на коллекцию AlbumEventTarget[]. При этом все дочерние сущности должны быть также корректно отображены.

var album = new Album();
album.Events.Add(createdEvent);
album.Events.Add(failedEvent);
album.Events.Add(cancellationEvent);

var eventsMapped = Mapper.Map<IList<IAlbumEvent>, IList<AlbumEventTarget>>(album.Events);

Mapping hierarchy to DTO

Рассмотрим такой case, как отображение иерархии в DTO (Data Transfer Object). С одной стороны уже знакомая иерархия объектов (domain model).

С другой стороны, простой плоский DTO.

Предполагается, что все специфические поля таких событий, как Cancellation, Failure, Restart, будут отображаться на один элемент данных Details. За счет этого иерархия "схлопнется" в плоский DTO.

Mapper.CreateMap<IAlbumEvent, DTO>()
    .MapGenericAlbumEventDataToDTO()
    .Include<ProcessingCancelledAlbumEvent, DTO>()
    .Include<FailedAlbumEvent, DTO>()
    .Include<RestartAlbumEvent, DTO>();

Mapper.CreateMap<ProcessingCancelledAlbumEvent, DTO>()
    .MapGenericAlbumEventDataToDTO()
    .ForMember(s => s.Details, m => m.MapFrom(s => "Actor: " + s.Actor + "; Comment: " + s.Comment));
Mapper.CreateMap<FailedAlbumEvent, DTO>()
    .MapGenericAlbumEventDataToDTO()
    .ForMember(s => s.Details, m => m.MapFrom(s => "Reason: " + s.Reason + "; Origin: " + s.Origin));
Mapper.CreateMap<RestartAlbumEvent, DTO>()
    .MapGenericAlbumEventDataToDTO()
    .ForMember(s => s.Details, m => m.MapFrom(s => "Reason: " + s.Reason));
                

var albumEvent = new ProcessingCancelledAlbumEvent("actor")
{
    EventID = 1,
    Status = AlbumStatusEnum.Created,
    Timestamp = new DateTime(2010, 1, 1),
    Type = EventType.Restart,
    Comment = "comment"
};

var target = Mapper.Map<IAlbumEvent, DTO>(albumEvent);

К сожалению, этот код не работает как ожидается. Вместо меппинга связки "ProcessingCancelledAlbumEvent-DTO" происходит меппинг связки "IAlbumEvent-DTO". По всей видимости Include ожидает, что оба и TSource и TDestination будут дочерними сущностями. В нашем же случае CancellationAlbumEvent наследуется от IAlbumEvent, а DTO один единственный, и тут просто нет иерархии и нет дочерних сущностей.

На мой взгляд, меппинг "Hierarchy - DTO" более распространенный case, чем "Hierarchy - Hierarchy", а он, к сожалению, не поддерживается.

Resources

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

2011-03-15T03:22:00.002+02:00

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

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

Debugging hell

Все из нас знают такой инструмент, как debugging. Сейчас очень редко приходится прибегать к нему, однако это не всегда было так. После написания программы, обычно довольно тривиальной, возникает желание убедиться в том, что то, что написано, это то, что мы хотели написать, а не то, что у нас получилось. Единственный инструмент, который имеется в наличии, или о которым мы знаем - это debugging. Ставим breakpoint в entry point программы, запускаем ёё, и начинаем отслеживать ход исполнения и верифицировать результаты.

Даже для программы с одной тривиальной задачей и одним сценарием, например, реализации алгоритма быстрой сортировки, процесс отладки может быть трудоемок и длителен, и занимать собственно больше времени, чем ушло на кодирование. По мере добавления новых возможностей в программу, сложность и количество возможных сценариев, которые нужно проверить, увеличивается экспоненциально, если не быстрее. Если вы помните бессоную ночь, проведенную за debugging, то это как раз тот случай. Иногда и такого инструмента как debugging в начилии нет, тогда все становится еще печальней.

Потратив массу времени на отладку и проверив все сценарии, к конце концов мы получаем заряд уверенности, что все ОК. Стоит отметить, что у другого человека, который не провел night full of debugging, такого заряда нет, и он вряд ли передастся ему от Вас. Что произойдет когда нужно будет внести изменения в поведение программы? Наша уверенность испарится немедленно. И здесь выбор невелик, либо снова засесть за debugging и пепроверить все сценарии, либо просто убедить себя, что все ОК. Если поджимают сроки, к примеру, сегодня защита курсового, то на первый вариант элементарно нет времени, даже если есть желание (хотя это вряд ли), и остается второй вариант. Что дальше? А дальше программа падает в самый не подходящий момент, например на презентации при защите перед комиссией.

Ручной запуск приложения в разных сценариях

Если приложение хоть немного сложнее, чем вывод на консоль "Hello %username%", то нам нужен код, который будет имитировать различные сценарии, запускать приложение, передавая ему подготовленные входные данные и зависимости. Обычно создается отдельное консольное приложение, либо меняется entry point самого приложения, чтобы работать как в production, так и в testing режиме.

public class Program
{
    public static void Main(string[] args)
    {
        var mode = (args != null && args.Length > 0 ? args[0] : "prod").ToUpper();
        if(mode == "PROD")
        {
            LaunchProgram();
        }
        else if(mode == "TEST")
        {
            TestProgramInScenarioA();
            //TestProgramInScenarioB();
            //TestProgramInScenarioC();
            //TestProgramInScenarioD();
            //TestProgramInScenarioE();
        }
        else
        {
            Console.WriteLine("Only prod and test modes are supported"); 
        }
    }
}

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

Интеграционные тесты в ручном режиме

В методы, которые на предыдущем этапе лишь имитировали сценарий для дальнейшей отладки, добавляется также проверка конечного результата работы программы на корректность. Эти, так называемые тесты, запускаются последовательно в ручном режиме. Если же программа падает на каком-то тесте, то дальнейшие тесты не запускаются, так как нету изоляции запуска тестов. В случае упавшего теста снова возвращаемся к debugging, до тех пор пока все тесты не будут успешно выполняться.

private void TestProgramInScenarioA()
{
    var sorter = new QuickSortAlgorithm();
    var sortedList = sorter.Sort(new[] {1, 2, 3, 4, 5, 6, 7}, true);

    VerifyEquality(sortedList, new[] {1, 2, 3, 4, 5, 6, 7});
}

private void TestProgramInScenarioB()
{
    var sorter = new QuickSortAlgorithm();
    var sortedList = sorter.Sort(new[] { 1, 2, 3, 4, 5, 6, 7 }, false);

    VerifyEquality(sortedList, new[] { 7, 6, 5, 4, 3, 2, 1});
}

private void TestProgramInScenarioC()
{
    var sorter = new QuickSortAlgorithm();
    var sortedList = sorter.Sort(new[] { 2, 5, 1, 4, 6, 3, 7 }, true);

    VerifyEquality(sortedList, new[] { 1, 2, 3, 4, 5, 6, 7 });
}

Из плюсов, добавилась автоматическая проверка результатов. Однако минусов по прежнему много.

Результаты не являются повторяемыми (repeatable).
Для того, чтобы автоматическая проверка стала возможной, конечный результат должен обладать свойством повторяемости, то есть оставаться неизменным в зависимости от времени запуска. Так как приложение тестируется в целом, то есть тест интеграционный, то на конечный результат влияет множество факторов, как внутренних, так и внешних по отношению к приложению. Однако в отличии от внутренних факторов, которые можно контролировать, на внешние факторы повлиять зачастую не представляется возможным, что приводит к неповторяемым результатам.
Приложение вообще может не иметь осязаемого результата работы, который можно проверить в детерминированной манере.
Неудобство ручного запуска тестов.
Приходиться заниматься вопросами ручного запуска, организации, поддержки набора тестов, и каждый раз создавать для этого доморощенную инфраструктуру.
Debugging активность по прежнему доминирует в большом объеме.

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

Интеграционные тесты + unit testing framework

На этом этапе применяется один из unit-testing framework'ов, такой как NUnit, TestDriven.NET, MSTest, xUnit, ну и так далее.

Однако его применение ограничено использованием инфраструктуры, которую предоставляет framework для автоматического запуска набора тестов в изолированном режиме. Подход к тестированию остается прежним: интеграционные тесты, и проблемы, обозначенные в предыдущей главе, остаются.

На этом этапе может поменяться подход к именованию тестов. Тестов становится больше, и названия типа TestApplicationInScenario111 начинают вызывать отвращение.

[Test]
private void TestQuickSortInAscOrderOnAlreadyPresortedData()
{
    var sorter = new QuickSortAlgorithm();
    var sortedList = sorter.Sort(new[] {1, 2, 3, 4, 5, 6, 7}, true);

    VerifyEquality(sortedList, new[] {1, 2, 3, 4, 5, 6, 7});
}

[Test]
private void TestQuickSortInDescOrderOnReversedData()
{
    var sorter = new QuickSortAlgorithm();
    var sortedList = sorter.Sort(new[] { 1, 2, 3, 4, 5, 6, 7 }, false);

    VerifyEquality(sortedList, new[] { 7, 6, 5, 4, 3, 2, 1});
}

[Test]
private void TestQuickSortInDescOrderOnRandomInputData()
{
    var sorter = new QuickSortAlgorithm();
    var sortedList = sorter.Sort(new[] { 2, 5, 1, 4, 6, 3, 7 }, true);

    VerifyEquality(sortedList, new[] { 1, 2, 3, 4, 5, 6, 7 });
}

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

The name of this tests SUCKS BALLS and does not clearly convey the intent of the test.

Также можно интегрировать запуск тестов в continuous integration процесс, если конечно на данном этапе мы уже практикуем continuous integration. А если учесть что тесты интеграционные, и их результаты непредсказуемы, то применение этого подхода не несет никакой пользы.

Переход от интеграционных тестов к unit тестам

Здесь приходит понимание, что тестирование конечного результата работы приложения либо какой-то из его подсистем не является гарантией корректного поведения приложения. Область тестирования сужается от уровня системы либо подсистемы к отдельным ее модулям и отдельным аспектам их работы.

Свойства хорошего unit-test'а

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

Repeatable
Для того, чтобы автоматическое тестирование стало возможным, надо обеспечить повторяемость результатов тестов (repeatable test). В этом состоит главное отличие от интеграционных тестов, результат работы которых непредсказуем. Если мы написали модульный тест, который не обладает свойством повторяемости, то это просто маленький интеграционный тест.

Вне зависимости от выбора уровня детализации модуля, если модуль в свою очередь зависит от других модулей (подсистем, систем), которые в данном случае играют роль внешних факторов, на которые мы повлиять не можем, но которые в то же время влияют на результат, то результат становится недетерминированным и неповторяемым. Следовательно, логика модуля должна тестироваться в изоляции от внешних зависимостей и факторов. Внешние зависимости заменяются искусственными сущностями, на которые можно повлиять. Приходим к идее использования fakes, в форме stubs and mocks.
Independent
Выполнение тестов не должно быть зависимо друг от друга, от порядка вызова тестов, от результата выполнения других тестов. Иначе их результаты не будут repeatable.

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

Идея состоит в том, чтобы в случае упавшего теста, можно было уверенно указать на проблему, не прибегая к ручной отладке. В идеале для понимания проблемы должно быть достаточно взглянуть на название теста. Если не помогло, далее на код теста. Отсюда следует, что тест должен быть написан профессионально (professional), быть читабельным (readable), лаконичным, в написании теста должны применяться те же практики и принципы, что и при написании production кода. Если и названия кода теста для понимания проблемы недостаточно, то это весьма плохо, в этом случае приходится заглядывать в code under test, либо что еще хуже, прибегать к debugging.
Thorough

Code coverage аспектов работы модулей должно стремиться к 100%.

Maintainable

Так как уровень детализации тестов переместился на отдельные модули системы, то количество тестов значительно вырасло. А значит уровень maintainability становится жизненно важным фактором. В противном случае можно создать массу кода, покрыть ёё не меньшей массой тестов, радоваться 100% покрытию. А при добавлении новой функциональности либо изменении уже существующей, придется выкинуть написанные тесты и переписать заново, так как уровень их поддержки равен нулю. Нужно применять профессиональный подход в написании теста, обеспечивать readability, brevity, контролировать количество тестов, решать вопросы организации тестов, поддерживать их в актуальном состоянии. Тесты, которые не поддерживаются в актуальном состоянии, становятся балластом, а от балласта рано или поздно избавляются. В таком случае написание тестов - это пустая трата времени и сил.

Fast
Так как количество тестов потенциально велико, то они должны выполнятся быстро, иначе не будет возможным запускать их часто. Если есть тесты, которые выполняются медленно, то нужно выделить их в отдельную категорию. К примеру, быстрые тесты запускать на постоянной основе в процессе кодирования, медленные тесты запускать только перед коммитом изменений.
Automatic
Весь набор тестов должен запускаться автоматически. Максимальные усилия, которые нужно приложить для запуска тестов, должны ограничиваться нажатием одной кнопки. В идеале запуск должен быть автоматизирован и интегрирован в процесс билда в рамках continuous integration процесса.
Professional
Readable

Benefits

Проанализируем выгоды полученные от применения модульного тестирования.

Набор тестов позволяет с большей долей уверенности гарантировать корректное поведение приложения.
Набор тестов позволяет доказать, что код работает.
Наличие постоянной обратной связи от системы. Последствия внесения изменений становятся предсказуемыми.
Написание тестов поощряет и принуждает к хорошему дизайну системы.
Облегчение регресионного тестирования, уменьшение количества дефектов в production коде.
Тесты служат в качестве up-to-date документации кода модулей.
Обретение чувства спокойствия, уверенности.

При внесении изменений, сразу можно оценить последствия внесенных изменений, понять что и где сломалось и сломалось ли вообще. Не нужно для этого проводить многочасовой debugging session. Исчезает страх внесения изменения, страх сломать случайно что-то в другом конце системы. Появляется уверенность в корректной работе системы. Уменьшается количество дефектов в production коде. А если дефект все-таки обнаруживается, то нету чувства паники и беспокойства, взамен приходит чувство спокойствия и уверенности.

Для обеспечения независимости и повторяемости теста, нужно чтобы модуль был спроектирован таким образом, чтобы допускать тестирование его логики в изоляции от других компонент. Таким образом поощряется применение SOLID принципов, single responsibility principle, dependency isolation, dependency injection. В прошлой своей статье я описывал вопросы, посвященные управлению зависимостями между модулями системы.

Тесты, которые обладают описанными свойствами могут служить в качестве документации кода и поведения системы. Документация, внедренная в код модулей, зачастую устаревает, и при внесении изменений в модуль, документацию, например в виде комментариев, лень обновлять или нет времени. Так как тесты поддерживаются в актуальном состоянии, то такая документация никогда не устаревает и всегда находится up-to-date. В будущем, для того, чтобы понять что делает код, не нужно смотреть на код, достаточно посмотреть на тесты, а в идеале, лишь на названия тестов.

Вопросы, на которые нет ответов

При процессе применения unit-testing незамедлительно возникают такие вопросы.

Что тестировать?
Что не тестировать?
Каков должен быть уровень детализации тестов?
Как именовать тесты?
С чего начинать написание тестов?
С чего начинать написание кода модулей?

Модульное тестирование, будучи инструментом, а не методологией, не в состоянии дать ответы на эти вопросы. Инструмент не знает сам по себе, как правильно он должен применяться. Ответы на эти вопросы дают уже такие методологии, как test-driven development, behavior-driven development.

Обычно тех, кто находится на этом этапе познания, можно охарактеризовать следующими утверждениями:

Задаются вопросом, как можно писать тесты до того, как написан код модуля (test-first), и пытаются это делать.
Количество тестов, уровень покрытия и уровень их детализации определяют интуитивно. Обычно это приводит к увеличению массы тестов и уменьшению их сопровождаемости.
Думают, что то, чем они сейчас занимаются - это и есть test-driven development. Нужно заметить, что на это убеждение большое влияние оказывает сбивающее с толку название этой методологии, а именно, наличие слова "test".

Test-first development

Сюда переходят те, кто понял, что значит написание теста до того, как написан код. А поняв это, они понимают еще много других вещей, хотя возможно не сразу. Основные идеи таковы.

Основное отличие от unit-testing практики состоит в том, что вместо концентрации на тестировании функциональности модуля, разработчик концентрируется на дизайне модуля и осмыслении его поведения до реализации логики модуля. Применение test-first подхода заставляет сначала задуматься над требованиями, осмыслить их, понять, затем преобразовать требования в набор тестов, и только затем приступить к реализации логики модуля. Разработчик вынужден проводить глубокий анализ требований перед тем, как приступить к кодированию. Это уменьшает вероятность того, что модуль, будучи реализованным, потребует изменения из-за недопонимания требований.

После того как требования ясны и поняты, они описываются в виде тестов. Код тестов становится первым клиентом кода модуля и вносит ясность в каких сценариях используется модуль и описывает различные варианты использования модуля. Вследствие этого дизайн модуля может быть спроектирован на основании конкретных вариантов, сценариев использования, требований, а не на основании абстрактных предположений разработчика. Фокус смещается на проектирование дизайна модуля. Test-first подход позволяет создавать удобный для использования API модулей.

Test-first подход поощряет такой важный принцип, как simplicity. Нужно написать ровно столько кода модуля, чтобы выполнились все тесты, а так как тесты - это воплощение требований к модулю, то выполнение всех тестов - означает, что модуль удовлетворяет всем предъявленным к нему требованиям. Это позволяет не удариться в over-engineering и поощряет принципы KISS (keep it simple, stupid) и YAGNI (You ain't gonna need it), то есть делать только то, что действительно нужно в данный момент и делать это максимально просто.

Если подытожить, то test-first подход смещает фокус от верификации корректного функционирования кода в сторону осмысления требований и поведения, построения дизайна системы.

Test-driven development

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

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

Changes in development process

Основное отличие TDD от TFD состоит в том, что TDD привносит изменения в процесс разработки. Грубо говоря:

TDD = TFD + Changes in development process.

Хотя используя TFD в полном объеме, процесс разработки меняется так или иначе. Так что надо заметить, что разделение TDD и TFD здесь несколько искусственно.

Проанализируем этапы, приведенные на диаграмме:

Собрать и проработать набор требований.
Написать тест, отражающий одно из требований.
Ни единой строчки кода реализации еще не написано. По мере написании тестов начинает вырисовываться API модуля. К концу написания тестов API модуля готов настолько, насколько нужно, чтобы код скомпилировался.
Убедиться что тесты падают.
Написать код модуля.
Запустить тесты, убедиться что они выполняются, иначе вернуться к предыдущему пункту.
Провести рефакторинг кода.

Место рефакторинга в TDD

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

Место рефакторинга в этой схеме не случайно. Что понять почему все именно так, нужно вспомнить что такое рефакторинг. Правильно, это такое изменение внутренней реализации, которое не меняет поведение. Главное здесь - это фраза "не меняет поведения". А что представляет из себя тест в TDD? Декларацию поведения. Из этого следует, что рефакторинг не должен потребовать изменение тестов. Розумеется, рефакторинг API модуля потребует внести соответствующие изменения в реализацию теста, но лишь в реализацию, декларация поведения останется неизменной. Основная функция тестов во время проведения рефакторинга - проверка того, что его проведение не изменило поведения.

TDD essential

Еще одна функция тестов в TDD - это мерило выполненной работы. Тесты, будучи декларацией поведения, представляют business value. Количество успешно выполняющихся тестов относительно общего их количества представляет процент выполненной работы. И когда Вам задают вопрос "Сколько работы сделано?", "Сколько еще осталось сделать?", "Когда будет закончена задача?", то можно больше не мычать, а достаточно взглянуть на test report, оценить количество выполняюших тестов, и дать конкретный ответ.

Очень важно понять, что изначальная функция тестирования, как верификации корректного функционирования модуля, отошла на второй план. Ее место заняла функция декларации требований и поведения, и верификация поведения. Нужен shift in mind, чтобы понять это, и что еще важнее, чтобы осознать и принять это, начать использовать и пожинать плоды.

Вопросы, на которые есть ответы

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

Что тестировать?, Что не тестировать?
Вспомнив, что цель теста - не тестирование, а декларация поведения, вопрос отпадает сам собой. TDD не занимается тестированием, значит вопросы "Что тестировать?" и "Что не тестировать?" просто неуместны. Если задать вопрос "Какое поведение описывать?", то ответ на этот вопрос понятен: "Поведение определяется требованиями и становится известно после анализа.". Behavior driven development уточняет ответ на этот вопрос еще больше.
Как именовать тесты?

Именование теста должно отражать поведение, которое он описывает. Глядя на название теста, можно назвать и понять описанный аспект поведения, не заглядывая в код теста.
```
[Test]
public void When_data_ordered_in_asc_order_should_be_able_to_sort_in_desc_order()
{
    var sorter = new QuickSortAlgorithm();
    var sortedList = sorter.Sort(new[] { 1, 2, 3, 4, 5, 6, 7 }, false);

    VerifyEquality(sortedList, new[] { 7, 6, 5, 4, 3, 2, 1 });
}
```
Обобщим это утверждение на группу тестов определенного модуля. В идеале, набор названий тестов должен позволять воссоздать модуль и его реализацию заново. Множество тестов полно и недвусмысленно описывает поведение модуля, и этого должно быть достаточно для воссоздания модуля, как если бы мы потеряли его код, но остались бы тесты.
С чего начинать написание тестов?
Выделить наиболее важное поведение и выразить его в виде теста. Двигаться далее в порядке важности.
С чего начинать написание production кода?
К концу написания набора тестов, API модуля готов. Далее берем тест, отражающий наиболее важное поведение, и пишем production code до тех пор, пока тест не начинает выполняться успешно. Далее, переходим к следующему требованию в порядке важности.

Why TEST-driven development?

"А почему TDD называется так как он называется? Что там делает слово test?". Если у Вас возник этот вопрос, значит Вы постигли TDD, и для вас TDD перестало быть еще одним buzzword в software development. Слово "test" в названии только сбивает с толку, и вносит неопределенность и путаницу. Слово "behavior" было бы более уместно.

Behavior-driven development

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

BDD масштабирует принципы TDD на фазы анализа требования, дизайна и реализации.

Что это значит? Попробую объяснить. Простите мой paint.

TDD предполагает, что разработчик занимается спецификацией поведения системы в виде набора тестов, что позволяет сформировать дизайн, после чего можно перейти к этапу реализации логики. Также предполагается, что требования уже известны на нужном уровне детализации (скажем отдельного класса). Однако эта информация не является первичной. Требования к системе уже описаны заказчиком до того, как разработчик приступил к кодированию.

В TDD единственная роль - это разработчик. ТDD сфокусирован на этапах дизайна системы и ее реализации. BDD помимо фазы дизайна и реализации, охватывает также фазу анализа требований и вопросы коммуникации, устанавливает связь между top-level требованиями уровня заказчика, и low-level набора поведений, которыми оперирует тестировщик либо разработчик. Другими словами, BDD расширяет методологию анализа требований и спецификации поведения на весь процесс и команду и унифицирует ёё.

И заказчик, и тестировщик, и разработчик занимаются описанием требований и поведения системы на разных уровнях ёё детализации. Другие участники процесса разработки эти требования потребляют. Чтобы добиться связи между требованиями и поведениями, сформированных разными участиками, на различном уровне, в различные моменты времени, и обеспечить коммуникацию участников процесса, применяется единый язык анализа и формализации требований и поведения. Единый язык поощряет взаимодействие членов команды в процессе сбора и понимания требований.

Унификация языка анализа требований

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

Feature/Goal, то есть та функциональная возможность, которая по тем или иным причинам нужна заказчику.
Role, субъект системы, которому необходима эта возможность, тот, кто будет использовать feature.
Benefit/motivation. Выгода, полученная от использовании feature, а также мотивация заказчика, которая объясняет, почему возникла необходимость в feature. Мотивация фокусируются на первичной цели, обеспечивает более глубокое понимание потребностей заказчика в целом, и направляет анализ требований в нужное русло.

Использование этих элементов ничуть не ограничивает нас в описании требований, а лишь слегка их формализует, определяя что-то вроде довольно свободного и гибкого шаблона. Конкретный пример шаблон может быть таковым: "As a [role] I want [feature] so that [benefit]". Главное здесь конечно же не wording или то, как построено предложение.

Сформированная история сохраняется в backlog'e до тех пор, пока не настанет пора ее воплощения в жизнь. C наступлением этого момента проводится сбор и анализ требований, обсуждения как внутри команды, так и с заказчиком, оценивается объем работы. История и набор собраной информации в целом определяют поведение, которое формализуется в виде набора критериев приемки (acceptance criteria). Удовлетворение всех критериев приемки со стороны системы означает корректность поведения системы.

Acceptance criteria - это спецификация поведения. Язык его описания должен быть гибким и свободным, и не ограничиваться применением в одной или нескольких предметных областях. BDD предлагает использование следующих элементов:

Given initial context, определяет исходный контекст, сценарий.
When event occurs, определяет совершаемое действие.
Then ensure outcomes, верифицирует последствия совершенного действия.

Making acceptance criteria executable

Имея в качестве исходной информации набор спецификаций поведения (acceptance criteria), разработчик может начать переносить их в код, то есть превращать их в форму выполняемых спецификаций (executable specification). Розумеется, это будут не юнит-тесты. Спецификации служат в качестве starting point для начала работы. По мере кодирования спецификаций формируется дизайн системы. Для модулей, появившихся в результате этого дизайна, определяются дочернии истории и спецификация поведения этих модулей, которые в свою очередь тоже переносятся в код. Процесс итеративно продолжается до тех пор, пока дальнейшее разбиение модулей станет нецелесообразным. В таком случае, спецификации нижнего уровня будут представлять собой юнит-тесты, а более высоких - интеграционные тесты, если проведение параллели с тестами здесь вообще уместна.

Если обобщить сказанное выше, то BDD подготавливает информацию, которая используется как исходная для применения TDD.

Вот что пишет по этому поводу Scott Bellware в своей статье.

Usually, the acceptance criteria are taken directly from the form written by the customer in the customer's comforable language, and translated directly into code by the developer who uses the customer's specified criteria and any notes that he's made in the conversation with the customer to get into any greater details.

You aren't trying to achieve seamless traceability of requirements with user stories and acceptance criteria. You're capturing just enough specification to get the work started.

Any new criteria that surface in the process of elaborating on a user story in code are captured directly in code, and can be communicated back to the customer later if necessary.

Describing acceptance criteria in natural language

Acceptance criteria пишутся людьми на простом английском языке. Будучи написанными, они переносятся в код при помощи unit testing либо specification framework. При переносе в код, язык описания спецификации не изменяется, используются те же языковые элементы такие, как given, when, then. Также применяется словарь предметной области, полученный в результате domain driven design.

К примеру, поведениt калькуляции расходов на доставку заказов, описанная при помощи MSpec.

[Subject(typeof(ShippingTablePostageCalculator))]
public class when_table_contains_record_with_matching_mail_class_and_distance 
    : given_shipping_table_postage_calculator
{
    static Money PostagePrice;

    Establish postage_calculator = () => WithShippingTable(
        new PostageRecord {MailClass = "FIRST_CLASS_MAIL", Distance = 1.00, Price = new Money(1.0m, "USD")}, 
        new PostageRecord {MailClass = "FIRST_CLASS_MAIL", Distance = 2.00, Price = new Money(2.0m, "USD")},
        new PostageRecord {MailClass = "PRIORITY_MAIL", Distance = 1.00, Price = new Money(5.0m, "USD")});

    Because of = () => { PostagePrice = Calculator.GetPostagePrice("FIRST_CLASS_MAIL", 1.00); };

    It should_get_postage_price_from_the_that_record = 
        () => PostagePrice.ShouldEqual(new Money(1.0m, "USD"));
}

Что за WTF!!??? Это что такое!!??? Если это было вашей первой мыслью при просмотре этого кодf, то могу сказать, что я подумал бы то же самое на Вашем месте. И не спрашивайте меня: "А что, для каждого теста нужно создавать новый класс?". Не будем сейчас углубляться в детали реализации конктреного framework. Это уже тема для отдельного поста.

С точки зрения написания теста (по уровню детализации в примере это таки юнит-тест) произошли следующие изменения по сравнению с TDD. Произошел переход от понятия теста к понятию спецификации, как элемента описания и верификации поведения. Поведение декларируется не только в имени теста, но и в его теле. Тело теста структурировано таким же образом, как и acceptance criteria, который оно представляет. Слово тест больше нигде не упоминается, ни в названии, ни в элементах framework, нету атрибутов Test, TestFixture, нету конструкций типа Assert.AreEqual(), на их место пришли поняти given/when/then(should).

Обощив, можно сказать, что BDD/specification framework не позволит писать тесты/спецификации и не быть ориентированным на поведение, она не просто поощряет, она принуждает отталкиваться от поведения. Это противоположно тому, как можно было писать тесты при помощи unit-testing framework не до, а после написания кода модулей, и говорить что вы занимаетесь test-driven development'ом. BDD буквально пропитывает понятием "поведения" все, начиная от анализа требований и заканчивая тестированием. Явная фокусировка на поведение - это то в чем TDD испытывает недостаток.

И напоследок...

Если BDD кажется Вам туманной материей, или Вас часто посещали вопросы типа "WTF?" при прочтении последней главы, то это нормально. Что касается меня, то хотя идея BDD мне и понятна, однако остается довольно много вопросов практического применения, на которые у меня пока нет ответов. В любом случае, думаю не стоит быть категоричным и отклонять BDD, только потому что класс с названием "when_table_contains_record_with_matching_mail_class_and_distance" выглядит ну по меньшей мере странно.

Также, стоит задать себе вопрос, на самом ли деле мы практикуем test-driven development, применяя практику юнит тестирование? Или мы занимаемся лишь покрытием кода модульными тестами, используя при этом unit testing и mocking frameworks? Иногда я ловлю себя на этом.

Полезные ссылки

Книги по unit-testing

Test driven development

Behavior driven development

Introducing BDD by Dan North.
Behavior-Driven Development. Статья must-read.
BDD on wiki.
Streamlined BDD Using SubSpec for xUnit.NET.
What's in a story.
Здесь и здесь уже с упором на использования конкретного framework'a.

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

2011-02-28T05:13:00.006+02:00

Статья посвящена управлению зависимостями между компонентами в приложении, рассматриваются такие концепции как 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 несет.

Содержание:

Вопрос управления зависимостями между компонентами в приложении
Классический подход к управлению зависимостями внутри компонент приложения
- Анализ проблем
Использование Service Locator
Использование Dependency Injection / Inversion of control container
- Dependency injection options
- Lifecycle and lifestyle explained
Service Locator vs DI/IoC Container
- Common service locator
Реализации IoC container'ов
Полезные ресурсы

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

Объектно-ориентированный подход предписывает использовать объект как единицу повторного использования, а приложение строить в виде набора компонент, которые объединяются в систему, между которыми устанавливаются различного рода связи и зависимости, и как результат, эта структура позволяет реализовать определенные use case'ы. С эволюцией приложения количество компонент растет, а вместе с ними растет и количество зависимостей между ними, таким образом структура приложения усложняется, и ей становится сложно управлять.

Чтобы не быть голословным, в качестве примера рассмотрим гипотетическую cистему упаковки заказов для дальнейшей отправки их конечному пользователю интернет-магазина, который специализируется на электронной технике. Описание некоторых компонент:

ShippingMethodCapabilities - позволяет определить может ли упакованный заказ быть отправлен конкретной службой доставки, в качестве критериев могут выступать размер, вес, содержимое упаковки, тип тары.
IPostalService - адаптер к сервису служб доставки (USPS, FedEx, UPS), знает как разговаривать с этими сервисами, отправляет им запросы на получение различной информации и получает от них ответы.
IPackingAlgorithm - представляет алгоритм упаковки предметов заказа. Различные алгоритмы смоделированы в виде таких классов, как TightPackingAlgorithm, SafePackingAlgorithm, TaggedPackingAlgorithm, WeightLimitedPackingAlgorithm.
IBox - предоставляет разные тип упаковки (в нашем примере: Small, Medium, Large).
DeviceWeightCalculator - считает вес контейнера, включая его содержимое, либо отдельно вес каждого устройства.

Предположим, разработчик воплотил в жизнь Single Responsibility Principle и спроектировал компоненты таким образом, что каждый занимается своим делом и делает это хорошо, и не знает больше чем ему это надо. Но редкий компонент живет в изоляции, он использует другие компоненты (зависимости), те в свою очередь используют свои, и т.д. Выстраивается структура приложения, причем структура эта далеко не статична, она динамична, она изменчива в зависимости от сценария использования приложения. На то компоненты и являются еденицами повторного использования, чтоб их использовать в разных сценариях.

В таком случае возникает необходимость помимо реализации "полезной" логики компонент, еще заниматься и управлением зависимостями между компонентами, чтобы построить структуру приложения. В понятие управления зависимостями входят такие активности:

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

И тут разработчик сталкивается с вопросом: "Где в приложении разместить всю эту логику управления зависимостей?". И это важнее, чем вопрос: "Как реализовать эту логику?". Это и есть вопрос управления зависимостями. Далее будут рассматриваться возможные варианты решения этого вопроса.

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

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

public class DevicePacker
{
    private IPackingAlgorithm _algorithm;
    private ShippingMethodCapabilities _shippingMethodCapabilities;
    private BoxTracker_itemTracker;

    public DevicePacker()
    {
        // creation of required dependencies,  dependency managing logic
        _algorithm = new WeightLimitedPackingAlgorithm();
        _shippingMethodCapabilities = new ShippingMethodCapabilities(
            new FedexPostalService());
        _itemTracker = new BoxTracker();
    }

    public Package PackOrder(Order order)
    {
        //component own useful logic
        throw new NotImplementedException();
    }
}

Анализ проблем этого подхода.

Проанализируем различные use case, в которых может использоваться компонент приложения, и как это повлияет на логику управления зависимостей внутри этого компонента.

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

Для нашего примера это может означать, что правила упаковки для разных заказчиков могут предписывать использовать разные типы упаковк. А WeightLimitedPackingAlgorithm , который использует IBox не располагает знаниями, чтобы принять решение какую реализацию выбрать. В итоге приходится внутрь компонента передавать лишние данные для того, чтобы он мог создать все нужные ему зависимости. Стоит отметить, что лишние данные передаются через несколько слоев приложения, несмотря на то, что промежуточным слоям они вовсе не нужны. Смотрим код.
```
public class WeightLimitedPackingAlgorithm : IPackingAlgorithm
{
    private ItemInfoProvider _infoProvider;
    public WeightLimitedPackingAlgorithm(PackagingRuleProvider rules, Client client)
    {
        // this class does not use PackagingRuleProvider and Client at all
        // only pass them to the deeper layer
        _boxProvider = new BoxProvider(rules, client);
    }
}

public class BoxProvider
{
    private IList<IBox> _itemPackers;

    public ItemInfoProvider(
        PackagingRuleProvider packagingRuleProvider,
        Client client)
    {
        //composite dependency creation logic which depends on outer context data
        if(client.IsVIPClient && packagingRuleProvider.DoesClientSupportBigBoxes)
        {
            _boxes.Add(new BixBox());
        }
        else if(packagingRuleProvider.GetBoxWeightLimit < 20.Ounces())
        {
            _boxes.Add(new MediumBox());
        }
        else
        {
            _boxes.Add(new SmallBox());
        }
    }
}
```
Определение типа зависимости зависит от сценария использования либо от режима работы.
Компонент вынужден знать о конкретном use case, в рамках которого он выполняется, и учитывать это при разрешении зависимостей. В итоге теряется гибкость и возможность повторного использования компонента в других use case'ах. Также, при добавлении нового либо удалении старого use case'a приходится обновлять все компоненты, которые знают о них.

К примеру, на production environment правила упаковки хранятся в базе данных, а на test environment - в XML файле, который расположен локально на файловой системе. В таком случае конкретная реализация IRuleRepository будет варьироваться.
```
    public DevicePacker(Client client)
    {
        // dependency resolve depends on deployment scenario
        if(Configuration.IsTestMode)
        {
            var packagingRuleProvider = new XmlRuleProvider();
        }else
        {
            var packagingRuleProvider = new SqlRuleProvider();
        }
    }
```
Невозможность покрытия компонентов юнит тестами, которые бы верифицировали определенный аспект работы компонента в изоляции от его зависимостей.
Если компонент сам создает необходимые ему зависимости, то заменить эти зависимости на "fakes" в целях тестирования становится невозможным. В итоге можно прийти к такому workaround, то есть делать инъекцию зависимостей через read-write свойства.
```
[TestFixture]
public class TestPackagingCreator
{
    [Test]
    public void Should_pack_order_with_two_discs_in_single_mailer_if_rules_are_configured_as_not_vip()
    {
        var devicePacker= MockRepository.GenerateMock<DevicePacker>();
        var packagingRules = MockRepository.GenerateMock<PackagingRuleProvider>();

        // how to inject fake PackagingRuleProvider into DevicePacker instance???
        // let's expose dependency as read-write property and inject through it
        devicePacker.Stub(pc => pc.Rules).Return(packagingRules);
    }
}
```

Если компонент управляет временем жизни своих зависимостей, то он должен в какой-то момент времени уничтожать экземпляры созданных им зависимостей.

Логика компонента снова же усложняется и помимо "полезной" логики, нужно "keep in mind" корректно завершить жизненный цикл созданный им объектов.

    public Package PackOrder(Order order)
    { 
       // create WeightCalculator instance with lifetime scope per order packing      
       // and destroy it after order is packed
       using(var DeviceWeightCalculator = new DeviceWeightCalculator())
       {
            var package = _algorithm.PackOrder(order);
            var weight = weightCalculator.CalculateWeight(package);
            if(_shippingMethodCapabilities.DoesExceeds(weight))
            {
                // do something, for example, divide order in different packages
            }
            return package;
       }
    }

Время жизни зависимостей не может быть больше, чем время жизни самого компонента.
Теряется гибкость управления временем жизни зависимостей. Так как компонент рулит своими зависимостями, то время их жизни не может быть больше, чем время жизни самого компонента, так как тогда некому будет уничтожить зависимость, кроме как тому компоненту, который её создал.
При наличии shared dependency, то есть зависимости, которая используется разными компонентами в разное время, непонятно кто из компонент должен управлять этой зависимостью.
Что можно сделать в этом случае? Как сделать так, чтобы компоненты имели доступ к shared dependency?

Да-да, реализовать зависимость в виде Singleton. Но тут стоит вспомнить притчу: "Если у вас есть одна проблема и вы пытаетесь решить её с помощью Singleton, то у вас есть две проблемы". Я бы сказал, даже не две, а больше. Вот некоторые из них:
- Невозможность подмены зависимостей в тестах.
- Что делать если время жизни shared dependency ограничего неким scope, отличным от per-application lifetime scope, к примеру, per-client processing scope или per-order processing scope.
- Что делать, если доступ к зависимости происходит в мультипоточном сценарии? Надо еще наворачивать синхронизационные конструкции?
Другой вариант состоит в том, чтобы перенести управление зависимостью на уровень компонента, который является parent'ом для тех компонент, которым нужна зависимость, и прокидывать зависимость, созданную в parent'е, тому компоненту, где она используется. В сложном приложении с несколькими layer of indirection это означает, что помимо засорения parent компонента знанием о зависимости, которая ему совершенно не нужна, мы еще засоряем и все промежуточные слои приложения от parent'а и до целевого компонента ненужными знаниями. Также это делает наше приложение монолитным, и внесение изменений, которые затрагивают зависимость, либо parent component, либо политику lifetime зависимости скорее всего затронет все слои, через которые зависимость проброшена, и цена таких изменений будет велика.

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

Итак, на основе проведенного анализа, можно составить список проблем. Если копнуть глубже, думаю, список проблем будет больше.

Не соблюдается Single Responsibility Principle; компоненту необходимо помимо собственной "полезной" логики заниматься управлением зависимостями, и это получается у него плохо. Нарушается распределения знаний в системе. Различные части приложения засоряются знаниями, которые им на самом деле не нужны.
Увеличивается coupling (cвязанность) компонент внутри приложения.
Страдает re-usability компонента; компонент зависит от сценария использования, а сценарий использования зависит от компонента. Здесь можно провести параллель с нарушением Dependency Inversion Principle.
Дублирование логики; многие компоненты создают зависимости на основании одних и тех же факторов и логики. Если факторы меняются, то надо обновлять все компоненты.
Уменьшается maintainability приложения; Увеличивается цена и сложность внесения изменений.
Невозможность изолированного тестирования компонент; а это может повлечь невозможность применения test-first development, либо test-driven development, либо behavior-driven development подхода, а это значит, что список проблем, с которыми нам придется столкнуться, увеличивается.
Усложнение приложения; его структуры, потоков данных.
Уменьшается уровень readability кода.

Здесь возникает вопрос: "А не пытаемся ли мы заставить наши компоненты заниматься тем, чем они не должны заниматься?".

Возможно, отдельно взятые компоненты приложения - не лучшее место для размещения логики управления зависимостями. А почему бы нам не возложить эту обязанность на абсолютно другой компонент, не имеющий отношения к приложению, некий внешний компонент "X"? Тогда компоненты приложения вместо того, чтобы самим создавать зависимости, запрашивали бы компонент "X" предоставить им нужную зависимость.

Service Locator

Идея Service Locator состоит в том, что компоненты приложения сами не разрешают зависимости, а просят некий третий объект, Service Locator, предоставить им зависимость, который располагает знанием какую конкретную реализацию компонента предоставить в ответ на запрос и где ее взять.

    public DevicePacker(ServiceLocator serviceLocator)
    {
        // dependency resolving depends on deployment scenario
        _algorithm = serviceLocator.GetService<IPackingAlgorithm>();
        _shippingMethodCapabilities = serviceLocator.GetService<ShippingMethodCapabilities>();
        _boxTracker= serviceLocator.GetService<BoxTracker>();
    }

На самом деле, все что мы сделали, это лишь ввели еще один layer of indirection, и перенесли туда логику управления зависимостями, тем самым избавив компоненты приложения о необходимости знать о конкретных реализациях зависимостей, однако, теперь компоненты вынуждены зависеть от Service Locator и знать где его можно взять, чтобы получить нужную зависимость. В итоге, проблема лишь передвинута на уровень дальше.

Обычно проблема доступа к Service Locator из компонент приложения решается до боли известным способом: "Singleton". Да, чтобы компоненты приложения без лишней боли имели доступ к экземпляру Service Locator, этот самый Service Locator моделируется в виде Singleton.

public DevicePacker()
{
    // service locator is a singleton
    _algorithm = ServiceLocator.GetService<IPackingAlgorithm>();
    _shippingMethodCapabilities = ServiceLocator.GetService<ShippingMethodCapabilities>();
    _boxTracker = ServiceLocator.GetService<BoxTracker>();
}

Этот подход ничем не отличается от описанного выше, с тем лишь различием, что вместо моделирования многих компонент приложения как Singleton для доступа к ним, мы делаем это только с Service Locator'ом. И нам кажется, что на это можно закрыть глаза. Однако это вовсе не решает проблем, которые привносит использование Singleton, мы лишь уменьшаем масштаб бедствия и локализуем его.

И хотя Service Locator и решает частично некоторые проблемы из описанных выше, и его внедрение в legacy application позволяет уменьшить уровень связанности, но причина остается в прежнем виде:
Компоненты приложения инициируют процесс разрешения зависимостей (dependency injection), и не важно сами они это делают, или этим занимается Service Locator.

Dependency Injection / Inversion of Control Container

Идея состоит в том, чтобы не компоненты приложения просили зависимости у компонента "X" (контейнера компонент), а чтобы контейнер сам делал инъекцию зависимостей в те компоненты, которым они нужны. Тем самым мы инвертируем механизм инъекции зависимостей, и реализуем Hollywood principle, "Don't call us, we'll call you".

Отсюда и название Inversion of Control Container. Это название может быть сбивающим с толку, здесь важно понимать, что принцип Inversion of Control не является отличительной чертой контейнеров компонент, а является неотъемлимой чертой любого framework'a, и состоит в том, что application code не вызывает framework code, вместо этого framework code вызывает application code. Скорее нужно спросить: "К какому аспекту работы приложения применяется принцип inversion of control". Ответ: "Dependency injection". В итоге уточняем первоначальное название "IoC container" следующим "DI/IoC Container".

Основное преимущество использования DI/IoC состоит в том, что компоненты приложения освобождены от необходимости знать о контейнере, как это было в случае Service Locator, и не надо больше городить огород с Service Locator as a Singleton, и это позволяет нам решить проблемы описанные выше.

Dependency Injection Options

Если IoC Container занимается инъекцией зависимостей, то дизайн компонента должен позволять передать ему зависимость. Различают несколько вариантов передачи зависимостей в компонент.

Сonstructor injection
```
    public DevicePacker(
        IPackingAlgorithm algorithm,
        ShippingMethodCapabilities shipingCapabilities,
        BoxTracker boxTracker)
    {
        _algorithm = _algorithm;
        _shippingMethodCapabilities = shipingCapabilities;
        _boxTracker = _boxTracker;
    }
```
Все необходимые зависимости явно передаются компоненту через конструктор. Это наиболее предпочтительный подход. Так как зависимости передаются через конструктор, то невозможно создать компонент, если контейнер не располагает необходимыми зависимостями. Это лучше, чем создать компонент без нужной зависимости, и обнаружить эту проблему где-то намного позже. К тому же, код компонента становится более читабельным и не требующим разъяснений (self-explanatory), глядя лишь на конструктор можно понять какие зависимые компоненты нужны данному компоненту для работы.
Property Injection

    public DevicePacker(
        IPackingAlgorithm algorithm,
        ShippingMethodCapabilities shipingCapabilities)
    {
        _algorithm = _algorithm;
        _shippingMethodCapabilities = shipingCapabilities;
    }

    public BoxTracker BoxTracker { get; set; }

Зависимости передаются через свойства. Менее предпочительный вариант, обычно через свойства передаются опциональные зависимости, без которых компонент может продолжать корректно работать. К тому же мы нарушаем инкапсуляцию.

Method injection
```
    public DevicePacker(ShippingMethodCapabilities shipingCapabilities)
    {
        _shippingMethodCapabilities = shipingCapabilities;
    }

    public BoxTracker BoxTracker { get; set; }

    public void SetupAlgorithm(IPackingAlgorithm algorithm)
    {
        throw new NotImplementedException();
    }
```
Довольно экзотический вариант. Не встречал в практическом использовании, возможно его имеет смысл использовать, если есть legacy сomponent, который принимает зависимости через метод, и мы хотим прикрутить использование DI/IoC и не можем поменять method injection на constructor injection либо property injection.

Component lifecycle and lifestyle

В управление зависимостями входит не только dependency resolve и dependency injection, но также и управление жизненным циклом компонент. Раз логика управления зависимостями вынесена в контейнер, то управление временем жизни компонент также должно входить в его обязанности.

Стандартный lifecycle компонента с точки зрения контейнера тривиален:

Создание компонента.
Его использование.
Уничтожение компонента.

Необходимость осуществления контейнером этих шагов для конкретного компонента в конкретный момент времени регулируется политикой lifestyle, который указывается при регитсрации компонента в контейнере. Разные реализации контейнеров определяют разные наборы возможных lifestyle, однако можно выделить наиболее распространенные типы lifestyle'ов.

Transient, контейнер создает новый компонент каждый раз, когда осуществляется dependency injection. Контейнер не хранит ссылку на компонент, обязанность уничтожения компонента переносится на компонент приложения.
Singleton, контейнер создает один экземпляр компонента, время жизни компонента совпадает со временем жизни контейнера. Удовлетворяет все зависимости этим одним и тем же экземпляром.
Per Thread, создается один экземпляр компонента для каждого потока, время жизни компонента совпадает со временем жизни потока, то есть контейнер уничтожает компонент при завершении потока, в котором этот компонент был создан.
Per lifetime scope, приложение само определяет границы жизненного цикла, к примеру per-application, per web request, per client processing, per order processing. Контейнер хранит компонент и уничтожает его при выходе приложения из определенного lifetime scope.

Lifestyle компонента определяется при регистрации компонента в контейнера. Чтобы не углубляться в детали реализации, в этой статье возможные варианты регистрации компонент в контейнере рассмотрены не будут. Если есть интерес, то можно ознакомиться на примере регистрации компонент в Autofac'e.

Service Locator vs DI/IoC Container

Нередко Service Locator используется совместно с DI/IoC container'ом. Можно выделить два варианта такого совместного использования.

Service Locator внутренне реализован на основании DI/IoC container'a и запрашивает зависимости у контейнера.
Это не такой уж и экзотический case. Допустим, имеется существующее приложение, мы захотели прикрутить DI/IoC контейнер. Просто так это сделать у нас не получится, для этого скорее всего потребуется сделать редизайн компонент, чтобы они могли принять зависимость либо в форме Constructor Injection, либо Property Injection, и т.п. Также, скорее всего, сделать этот редизайн так, чтобы мы всецело переключиться на использование DI/IoC container у нас не получится. Вот тут на помощь приходит Service Locator. Однако у нас уже есть контейнер компонент, не хотелось бы в Service Locator'е дублировать логику контейнера, тогда делаем так, чтобы Service Locator запрашивал зависимости у контейнера, и возвращал их компонентам приложения.
```
public class ServiceLocator
{
    private IWindsorContainer _container;

    public ServiceLocator()
    {
        _container = new WindsorContainer();
        SetupContainer(_container);
    }

    public T GetService<T>()
    {
        return _container.Resolve<T>();
    }
}
```
DI/IoС контейнер injects Service Locator тому компоненту, где этот Service Locator нужен.
Внимание, в предущем предожении английских слов больше чем русских :). Иногда сложно выразить технические вещи на русском :(.

Это скорее логическое продолжение первого use case'а, когда у нас есть Service Locator и DI/IoC контейнер. Service Locator может быть реализован на базе контейнера, хотя в этом случае это необязательно. Здесь мы снова сталкиваемся с проблемой: "Как компонент приложения получит ссылку на Service Locator?". Только в этот раз вместо того, чтобы моделировать Service Locator в виде Singleton, мы регистрируем Service Locator в контейнере, и контейнер делает инъекцию Service Locator'a в нужное место.
```
public interface IServiceLocator
{
    T GetService<T>();
}

// service locator is based on DI/IoC container
public class CastleWindsorServiceLocator : IServiceLocator
{
    private IWindsorContainer _container;

    public CastleWindsorServiceLocator()
    {
        _container = new WindsorContainer();
    }

    public T GetService<T>()
    {
        throw new NotImplementedException();
    }
}

public class DevicePacker
{
    private IPackingAlgorithm _algorithm;
    private ShippingMethodCapabilities _shippingMethodCapabilities;
    private BoxTracker _boxTracker;

    // inject service locator into the component
    public DevicePacker(IServiceLocator serviceLocator)
    {
        _algorithm = serviceLocator.GetService<IPackingAlgorithm>();
        _shippingMethodCapabilities = serviceLocator.GetService<ShippingMethodCapabilities>();
        _boxTracker = serviceLocator.GetService<BoxTracker>();
    }
}
```

Сommon Service Locator

Ранее мы говорили, что при использовании Service Locator, компоненты приложения вынуждены знать о Service Locator'е в виде статической ссылки. Если Service Locator реализован на основании DI/IoC контейнера, то неплохо бы скрыть от компонента приложения внутреннюю реализацию Service Locator'а. Также нам может потребоваться заменить текущую реализацию контейнера на другую (Castle.Windsor на Autofac), и в этом случае мы не должны менять клиентов Service Locator'a.

Cмотреть сюда: Common Service Locator.

Реализации IoC Container'ов

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

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

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

Это дает дополнительную гибкость, и позволяет компонентам нe ссылаться на контейнер в виде прямой ссылки либо в виде Service Locator'а, а выражать требования к использованию зависимостей в виде различных типов отношений. Более детально здесь либо еще подробнее здесь. Но это скорее тема для отдельного поста.

Полезные ресурсы

В завершение статьи привожу список ссылок из своих bookmarks, которые могут быть полезны.

Приветствие

2011-02-08T00:47:00.001+02:00

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

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

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

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

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