Переопределение DefaultDeleteEventListener и DefaultLoadEventListener обеспечили действительно хорошее решение для реализации программных удалений с помощью Nhibernate.Soft Deletable с использованием свободного nhibernate и лишних ленивых нагрузок
public class SoftDeletableLoadEventListener : DefaultLoadEventListener
{
#region Non-public members
protected override object DoLoad(LoadEvent @event,
IEntityPersister persister, EntityKey keyToLoad,
LoadType options)
{
object entity = base.DoLoad(@event, persister, keyToLoad, options);
var softEntity = entity as ISoftDeletable;
if (softEntity != null && softEntity.IsDeleted)
{
if (options == LoadEventListener.ImmediateLoad
|| options == LoadEventListener.Load)
{
string msg =
string.Format("Can not Load soft deleted entity typeof({0}) with Id {1} as it was deleted.",
softEntity.GetType().Name,
softEntity.Id);
throw new InvalidOperationException(msg);
}
}
return entity;
}
#endregion
}
В резюме для DefaultLoadEventListener гласит: Определяет слушатель событий к нагрузке по умолчанию, используемые NHibernate для загрузки сущностей в ответ создаваемой нагрузки события.
Это означает, что при использовании ExtraLazyLoading фильтр не применяется, что приводит к: например, удаленным объектам. Есть ли другой способ применения мягких удаляемых фильтров во время запросов? Есть ли лучшие способы, которые всегда фильтруют добавление ограничений вручную?
Спасибо, это хороший момент, но я бы хотел найти более общее решение. –
«Более общий», я думаю, вы хотите сделать модификацию в 1 месте, а не обозначать каждую из своих коллекций с помощью спецификация where where? –
Да, это был бы самый аккуратный способ. Я думаю, что наличие соглашения о коде всегда добавлять предложение Where() для сопоставления коллекций немного громоздко. –