Единица работы, которую вы описываете, уже предоставлена NHibernate, поэтому нет никаких причин делать такую единицу работы.
То, что мы имеем в нашей Службе WCF, - это единица работы более высокого уровня, которая содержит информацию, важную в нашем приложении для текущей единицы работы. Это включает в себя абстрагирование NHibernate ISession для нас. Когда вы разбиваете его, у вас есть код, который вписывается в три категории
Код, который должен иметь дело с единицей работы. Неважно, кто поддерживает единицу работы. Это может быть NHibernate, iBatis или пользовательский ORM. Все, что нужно сделать, это загрузить, откатиться, сохранить и т. Д. Его не должно интересовать механизм, используемый для этого.
Код, который должен иметь дело с ISession напрямую, потому что он выполняет специфические для NHibernate вещи. Обычно это связано со сложными запросами, которые необходимо создать.
Не нужно знать, что он работает в единице работы или получить доступ к ISession. Мы можем полностью игнорировать это как часть этого обсуждения.
Хотя код в 1. может просто работать против ISession, мы предпочитаем абстрагироваться от кода, который мы не контролируем напрямую или который может измениться. Это имеет значение по двум причинам.
Когда мы начинали, мы не были на 100% проданы на NHibernate. Мы рассматривали iBatis или что-то на заказ. Очевидно, это больше не проблема.
Вся команда не является экспертом в NHibernate, и мы не хотим, чтобы они были. По большей части люди пишут код, который вписывается в категорию 1. Все, что они знают, это наша единица работы. Когда код в категории 2. должен быть написан, его пишут люди из команды, которые хорошо понимают NHibernate.
Итак, в заключение я бы сказал, что тип единицы работы, о которой вы говорите, не нужен, я бы сказал, что единица работы более высокого уровня может обеспечить большую ценность.