NHibernate. Mapping By Code. Вся модель в одну строчку.

  С появлением в Nhibernate 3.2 Mapping By Code маппить стало гораздо легче, приятней и быстрее (MappingByCode не требует десериализации xml). Но хотелось большего, что всё как-нибудь само замапилось. Это возможно без лишних усилий (спасибо Фабио за ConventionMapper), но соглашения по-умолчанию отличаются от моих собственных. Вот этот недостаток я решил исправить в проекте Enhima.
Использовать ее очень легко:

var config = new Configuration(); // Это обычный класс конфигурации NHibernate
config.MapEntities(From.ThisApplication()); // А это весь маппинг

  Enhima будет искать все сущности, находящиеся в текущем домене приложений, и автоматически маппить их по соглашениям.
 Я не буду рассказывать про все соглашения, их можно найти в коде. Но пара слов о главном:
Enhima ищет все объекты, наследующие класс Enhima.Entity. Это упрощённая версия AbstractEntity из проекта uNhAddIns. Но есть еще одна - сущность AggregateRoot. Enhima использует их для управления каскадным сохранением удалением, согласно идеям Эрика Эванса из книги DDD.
  Соглашения - это хорошо и быстро. Но что если соглашений недостаточно? Это не проблема, Enhima переопределит значения из маппинга по соглашениям значениями из ClassByClass маппингов (ClassMapping<T>, SubclassMapping<T>, UnionSubclassMapping<T>, JoinSubclassMapping<T>)  без дополнительных усилий.

 Полученные маппинги неплохо было бы протестировать. Для этого есть еще один метод:

var config = new Configuration(); // Это обычный класс конфигурации NHibernate
config.СonfigureSqlite(); // Для тестирования с файлом БД.
config.СonfigureSqliteInmemory(); // Для тестирования в памяти.

 Такая конфигурация вряд ли подойдёт для развёртывания, но для быстрых интеграционных тестов вполне.  В последнее время любой приличный проект под .net обязан иметь свой nuget. Enhima не исключение :) Правда, пока она находиться в стадии beta-тестирования. Поэтому для установки в проект стоит воспользоваться ключом -pre:

install-package enhima.entities -pre
install-package enhima.mapping -pre

Удачных маппингов!

MSBuild. TransformXml. Маленькая, но весьма досадная проблема.

  Недавно пришлось занимать простой вещью: есть проект, есть шаблон конфигурации. И для каждого развертывания системы надо заполнить свой шаблон. Ок, у нас есть решение. Берём TransformXml-Task для msbuild, и трансформируем конфиг:

<TransformXml 
  Source="someapp.config" 
  Transform="transform.xml" 
  Destination="someapp.config" />

  Выглядит просто, не так ли? Увы только выглядит. Сама по себе задача преобразования работает замечательно, только вот  TransformXml блокирует... Source! Чтобы понять, как это приятно попробуйте наложить несколько трансформаций на один файл. В итоге у меня вышло нечто подобное:

<Copy 
  SourceFiles="someapp.config" 
  DestinationFiles="someapp.config.1"/>
<TransformXml 
  Source="someapp.config.1" 
  Transform="transform1.xml" 
  Destination="someapp.config" />

<Copy 
  SourceFiles="someapp.config" 
  DestinationFiles="someapp.config.2"/>
<TransformXml 
  Source="someapp.config.2" 
  Transform="transform2.xml" 
  Destination="someapp.config" />

Не очень элегантно. И временные файлы нельзя удалить в процессе работы msbuild - они заблокированы. Весьма, весьма досадный баг, и молниеносная реакция на него. Может кто-нибудь знает способ лучше?