NHibernate много-к-одному «на лету»

Question

Я хотел бы знать, может ли следующая проблема может быть решена по-другому в NHibernate.

Допустим, мы в этом домене:

public class A 
{ 
    public virtual B LastAssociationWithB { get; set; } 
    public virtual ICollection<B> CollectionAssociationOfB { get; set; } 
} 

public class B 
{ 
    public virtual DateTime DateAdded { get; set; } 
} 

Свойство LastAssociationWithB представляет собой один из B постоянных объектов, связанных в собственности CollectionAssociationOfB коллекции.

На самом деле, LastAssociationWithB представляет собой последний B постоянный объект, добавленный по дате.

Так, в области, когда новый B добавлен в CollectionAssociationOfB, он также назначен LastAssociationWithB.

Это хороший способ последующего превращения кода в менее сложные запросы LINQ.

В любом случае, мой вопрос: Вы знаете какой-либо другой подход к этому? Например, какая-то ассоциация , которая создает SQL , присоединяется к капотам, поэтому вам не нужно иметь явное соотношение 1: n в таблице A, но оно будет поддерживать свойство класса?

Или мой нынешний подход рекомендуется для решения этого сценария?

Сторона примечания: в сценарии реального мира CollectionAssociationOfB является упорядоченным списком, так как упорядочение задается в конфигурации сопоставления NHibernate.

Answer 1

Вы можете указать связь, используя формулу:

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

Другой альтернативой является использование триггера для вставки в B для обновления столбца в A. Это имеет недостаток движущейся логики в базе данных, но это обеспечит согласованность без потенциального штрафа за производительность.

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

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