NHibernate: отношения многие-к-одному с использованием предварительно загруженных ссылок - PullRequest
1 голос
/ 21 февраля 2011

Я использую отношение «многие к одному» следующим образом:

Классы:

public class Account
{
    public virtual long AccoungID { get; set; }
    public virtual string UserName { get; set; }
}

public class AnotherClass
{
    public virtual long AClassID { get; set; }
    public virtual Account Account { get; set; }
}

Отображения:

  <class name="Account">
    <id name="AccountID">
      <generator class="hilo"/>
    </id>
    <property name="Username"/>
  </class>  

  <class name="AnotherClass">
    <id name="AnotherClassID">
      <generator class="hilo"/>
    </id>
    <many-to-one name="Account" class="Account" column="AccountID"/>
  </class>

Это работает нормально, с отложенным чтением свойства Account для экземпляра AnotherClass.

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

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

Из-за ленивого чтения я могу получить доступ к свойству AnotherClass.Account.AccountID без дополнительного выбора. Надеюсь, это поможет.

Я все еще хочу, чтобы операции добавления / обновления / удаления в объекте AnotherClass обновляли свойство AccountID.

Таким образом, вопрос заключается в следующем: как можно заполнить свойство Account данными из кэшированного списка вместо базы данных на основе AccountID из таблицы AnotherClass?

1 Ответ

1 голос
/ 21 февраля 2011

Поскольку учетная запись, которую вы кэшировали, принадлежит другому сеансу, я думаю, что вы можете создать перехватчик (смотрите здесь: http://weblogs.asp.net/srkirkland/archive/2009/09/03/simple-auditing-using-an-nhibernate-iinterceptor-part-2.aspx), и когда объект загружен, для которого требуется учетная запись, вы можете заблокировать ссылка на текущий сеанс и присвоение его свойству.Менее навязчивым способом можно внедрить самостоятельно (или использовать существующий) кэш второго уровня.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...