Это хорошая идея иметь несколько NHibernate EventListener?

Question

Мы только начинаем с NHibernate и рассматриваем NH Cookbook 3.0, в котором рассказывается об использовании EventListener для отметки объекта, который указывал, кто создал объект и когда, затем, кто изменил объект и когда.Сейчас мы рассмотрим реализацию прослушивателя событий отслеживания аудита (создание истории изменений значений свойств).Рекомендуется использовать два (или более) прослушивателя событий, каждый из которых обрабатывает одну задачу, или один обработчик событий, обрабатывающий несколько задач.

Таким образом, код прослушивателя одного события будет выглядеть примерно так:

public class EventListener : IPreInsertEventListener, IPreUpdateEventListener
{
    ...
    ...
    public bool OnPreUpdate(PreUpdateEvent e)
    {
        _stamper.Update(e.Entity as IStampedEntity, e.OldState, e.State, e.Persister);
        _auditTracker.Update(e.Entity as IAuditTrackedEntity, e.OldState, e.State, e.Persister);
        return false;
    }
}

Хотя модель слушателя двух событий будет выглядеть примерно так:

public class StamperEventListener : IPreInsertEventListener, IPreUpdateEventListener
{
    ...
    ...
    public bool OnPreUpdate(PreUpdateEvent e)
    {
        _stamper.Update(e.Entity as IStampedEntity, e.OldState, e.State, e.Persister);
        return false;
    }
}

public class AuditHistoryEventListener : IPreUpdateEventListener
{
    ...
    ...
    public bool OnPreUpdate(PreUpdateEvent e)
    {
        _auditTracker.Update(e.Entity as IAuditTrackedEntity, e.OldState, e.State, e.Persister);
        return false;
    }
}

Что считается наилучшей практикой, и есть ли какие-либо недостатки в производительности у обоих?Позднее (два отдельных прослушивателя событий) может показаться наилучшей реализацией как для уточнения, так и для сопровождения, но просто не уверен, что это вызовет у нас проблемы позже.

Answer 1

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

Answer 2

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

Это помогло бы с ремонтопригодностью, тестируемостью, повторным использованием и т. Д.