Какой самый простой способ сохранить NHibernate ISessionFactory для веб-страниц и веб-сервисов?

Question

Какой самый простой способ сохранить NHibernate ISessionFactory для веб-страниц и веб-сервисов?

Я попаду в Rhino Commons и Windsor и позже. Я ищу основную концепцию.

Это правильно?

Я пытался найти руководство о том, как обращаться с ISessionFactory как можно проще. Я также ищу решение, которое будет работать как на веб-страницах, так и на веб-сервисах. Примеры, которые я видел, имеют дело с веб-страницами и никогда не затрагивают тему веб-сервисов. Они начинают с создания модуля Http, который создает ISessionFactory и сохраняет его в статической переменной (например, HybridSessionBuilder Джеффри Палермо (jeffreypalermo.com/blog/use-this-nhibernate-wrapper-to-keep-your-repository-classes-simple/) ) или летом NHibernate (www.summerofnhibernate.com, см. StaticSessionManager в сеансе 13). Я также заметил, что, несмотря на то, что ISessionFactory реализует IDisposable, кажется, никто не избавляется от него. Я думаю, они просто позволяют утилизировать сборщик мусора. об этом, когда веб-приложение заканчивается, что произойдет, если IIS будет переработан или веб-сайт станет бездействующим.

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

Является ли это основным принципом поддержания ISessionFactory в живых?

Answer 1

Я думаю, вы в основном разобрались.

Причина, по которой никто не избавляется от фабрики сессий, заключается в том, что вы вообще не хотите этого делать. Создание фабрики сессий - чрезвычайно дорогая операция, которая может занять много секунд, поэтому вы хотите удерживать ее как можно дольше. Среда выполнения .NET фактически создаст пул HttpApplication s и может создавать / распоряжаться ими по желанию. Поэтому, если вы можете сохранить фабрику сеансов вне приложения в области AppDomain, это предпочтительнее, поскольку фабрика будет работать до тех пор, пока домен не будет перезагружен. Объявление фабрики сессий как статической позволит достичь этого, поэтому это сделано; см. MSDN документы по статическим классам:

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

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