Мне гораздо сложнее управлять сеансом в приложении для настольных компьютеров, потому что вы не можете воспользоваться таким ясным связующим, как HttpContext. Итак, как вы управляете своим сеансом жизни, чтобы воспользоваться ленивой загрузкой, но не открыв один сеанс для всего приложения?Какова стратегия управления сеансом для NHibernate в настольных приложениях?
Я думаю, что это сводится к дизайну ваших объектов. Поскольку ленивая загрузка может быть применена на уровне каждого объекта, вы можете воспользоваться этим фактом, когда думаете о управлении сеансом.
Например, у меня есть куча объектов, которые богаты данными и ленивы загружены, и у меня есть представление сетки/сводки и представление деталей для них. В представлении grid-summary я не использую ленивую версию объекта. Я использую суррогатный объект для представления этих данных, и этот суррогатный объект не лениво загружен.
С другой стороны, как только пользователь выбирает эту запись для просмотра/редактирования, и вы вводите многостраничный просмотр деталей объекта, то есть когда мы применяем ленивую загрузку к конкретному объекту. Данные теперь ленивы загружаются в зависимости от того, какие детали просматриваются только по требованию. Таким образом, объем моей сессии, открытой для ленивой загрузки, длится до тех пор, пока используется представление подробностей.
Как вы уже говорили, вы не можете использовать границу HttpRequest, но вы можете понять, что такое «HttpRequest» в вашем рабочем приложении.
Позвольте мне объяснить. Обычно ваш HttpRequest будет контроллером для действия, и вы ограничите свою сессию этим конкретным действием. Теперь в вашем рабочем приложении «контроллеры» (события) могут быть меньше, но, как сказал @Jon, окно может легко представлять границу: вы работаете с вещами там, пусть они будут на вашем сеансе.
Возможно, мы сможем создать шаблон команды. Каждое значащее событие будет подавать и запускать команду и выполнять ее. Основная реализация AbstractCommand.Execute() отвечает за инициализацию сеанса, завершение транзакции, вызов конкретной реализации SomeCommand._Execute() и закрытие всего содержимого.
Во всяком случае, это далеко не так, чтобы быть агностиком настойчивости, как и должно быть, когда я загрузил свой объект, и я (хочу) иметь дело только с обычными экземплярами (я в основном ссылаюсь на ленивую нагрузку здесь).
Возможно ли в противном случае реализовать какое-либо поведение автоматического открытия/автоматического закрытия? Это должно быть достигнуто за счет того, что уровень персистентности чувствителен к потребностям в запросах более высокими уровнями, даже в неявных случаях, таких как триггеры с ленивой нагрузкой. Что касается закрытия соединения, уровень сохранения может закрыться после заданного таймаута (10 секунд?) Бездействия БД. Я знаю, это не острый. Но это действительно сделало бы более высокий уровень устойчивости агностиком.
Спасибо, Марчелло
Ayende недавно написал a great article on the subject in MSDN.