2012-05-10 2 views
3

У нас есть наш первый проект NHibernate, который идет очень хорошо. Тем не менее, я до сих пор не понял полную картину того, как управлять сеансами и объектами в нашем сценарии.Объекты сущности и сеансы NHibernate

Итак, мы настраиваем структуру системы в постоянной модели объекта, хранящейся в базе данных с NHibernate.

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

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

Поскольку услуга представляет собой многопоточную систему, вопрос заключается в том, как управлять сеансами NHibernate.

Теперь я рассматриваю подход, в котором у нас будет только фоновый поток, который будет заботиться о сохранении объекта в фоновом режиме, а другие потоки просто помещают «SaveRequests» в наш репозиторий вместо прямого доступа к сеансам NHibernate. Таким образом, я могу использовать один сеанс для службы и управлять уровнем NHibernate, полностью отделенным от службы, и клиентами, которые обращаются к объектам.

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

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

Я на правильном пути или как мне следует продолжить?

ответ

2

Рассмотрите ISession единицу работы. Вы хотите определить в контексте своего приложения, что составляет единицу работы. Единица работы - это граница вокруг ряда небольших операций, которые составляют полную, функциональную задачу (полная и функциональная определяется вами при разработке вашего приложения). Это когда ваша служба отвечает на запрос клиента Silverlight или другой внешний запрос? Это когда служба просыпается, чтобы выполнить некоторую работу по таймеру? Все вышеперечисленное?

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

Идея, как правило, описывается как это:

  1. мне нужно сделать некоторую работу (потому что я в ответ на событие, будь то входящий запрос, работа по таймеру, Безразлично» неважно).
  2. Поэтому мне нужно начать новую единицу работы (которая помогает мне отслеживать все операции, которые мне нужно выполнять во время выполнения этой работы).
  3. Единица работы начинает новый ISession для отслеживания моей работы.
  4. Я делаю свою работу.
  5. Если бы я смог успешно выполнить свою работу, все мои изменения должны быть очищены и зафиксированы
    1. Если нет, сверните все мои изменения обратно.
  6. Очистить после себя (удалить ISession и т. Д.).
+0

Да, я это рассмотрел. Но поскольку у меня есть объекты живые «навсегда», я считаю, что UnitOfWork также должен жить вечно. Или как я могу связать изменения в одном сеансе с объектами, которые все время находятся в сеансе обслуживания? Основным интерфейсом являются не клиенты, а приложение-служба, отслеживающее состояние системы, и мы также имеем живые данные в объектах (например, состояние и текущие значения). –

+0

Я не могу придумать ни одного сценария, в котором вы бы хотели иметь «объекты живые» дольше, чем ~ 1 секунду ... – Phill

+0

Мы решили, что мониторинг основан на объектах, которые отслеживают текущий статус системы, поскольку это является основной частью. Их конфигурация сохраняется, но не текущее состояние в целом. –