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

Question

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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