Какова ваша стратегия управления сеансами для NHibernate в настольных приложениях?

Question

Я нахожу гораздо более сложным управлять вашим сеансом в настольном приложении, потому что вы не можете воспользоваться преимуществами такой четкой привязки, как HttpContext.Итак, как вы управляете временем жизни сеанса, чтобы воспользоваться преимуществами отложенной загрузки, но без открытия одного сеанса для всего приложения?

Answer 1

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

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

С другой стороны, как только пользователь выбирает эту запись для просмотра / редактирования, и вы вводите многостраничное представление сведений об объекте, именно тогда мы применяем отложенную загрузку к конкретному объекту.Данные теперь загружаются с задержкой в зависимости от того, какие детали просматриваются только по запросу.Таким образом, область действия моего сеанса, открытая для отложенной загрузки, длится только до тех пор, пока используется представление сведений.

Answer 2

Айенде недавно написал отличная статья на эту тему в MSDN.

Answer 3

Как вы говорили ранее, вы не можете использовать границу HttpRequest, но вы можете понять, что такое "HttpRequest" в вашем настольном приложении.

Позвольте мне объяснить.Обычно ваш HttpRequest будет контроллером для действия, и вы ограничите свой сеанс этим конкретным действием.Теперь в вашем настольном приложении "контроллеры" (события) могут быть меньше, но, как сказал @Jon, окно может легко представлять границу:вы работаете с этими вещами там, пусть они будут на вашем сеансе.

Answer 4

Может быть, мы сможем придумать, как настроить командный шаблон.Каждое значимое событие будет подавать и запускать Команду, а затем выполнять ее.Базовая реализация AbstractCommand.Execute() отвечает за инициализацию сеанса, завершение транзакции, вызов конкретной SomeCommand.Реализация _Execute() и закрытие всего содержимого.

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

Возможно ли в противном случае реализовать какое-то поведение автоматического открытия / автоматического закрытия?Это должно быть достигнуто путем повышения чувствительности уровня сохраняемости к потребностям запросов более высоких уровней, даже в неявных случаях, таких как триггеры отложенной загрузки.Что касается закрытия соединения, уровень сохраняемости может закрыться после заданного тайм-аута (10 секунд?) бездействия базы данных.Я знаю, это не остроумно.Но это действительно сделало бы высшие слои постоянными агностиками.

Спасибо, Марчелло