Най-добра практика по отношение на задействане и обработка на .NET събития

Има и трета опция: Отлагане на повдигане на събитието, докато заключването бъде освободено. Обикновено бравите се вземат за кратко време. Обикновено е възможно да се забави повдигането на събитието до след заключване (но в същата нишка).

BCL почти никога не извиква потребителски код под ключалка. Това е изричен техен принцип на проектиране. Например ConcurrentDictionary.AddOrUpdate не се обажда на фабриката, докато е под ключ. Това контраинтуитивно поведение предизвиква много въпроси за препълване на стека, тъй като може да доведе до множество фабрични извиквания за един и същ ключ.

Честно казано смятам, че вторият вариант е по-добър от гледна точка на принципа за разделяне на проблемите, тъй като кодът за задействане на събитие не трябва да предполага какво може или не може да направи манипулаторът на събитието.

Не мисля, че първият вариант нарушава разделянето на загрижеността. Извлечете AsyncEventNotifier клас и делегирайте вашия генериращ събитие обект към него, нещо като (очевидно непълно):

class AsyncEventNotifier
{
    private List<EventListener> _listeners;

    public void AddEventListener(EventListener listener) { _listeners.add(listener); }
    public void NotifyListeners(EventArgs args)
    {
        // spawn a new thread to call the listener methods
    }
    ....
}

class EventGeneratingClass
{
    private AsyncEventHandler _asyncEventHandler;

    public void AddEventListener(EventListener listener) { _asyncEventHandler.AddEventListener(listener); }

    private void FireSomeEvent()
    {
        var eventArgs = new EventArgs();
        ...
        _asyncEventhandler.NotifyListeners(eventArgs);
    }
}

Сега вашият оригинален клас не е отговорен за нищо, за което не е бил отговорен преди. Той знае как да добави слушатели към себе си и знае как да каже на своите слушатели, че е настъпило събитие. Новият клас знае подробностите за изпълнението на „кажи на своите слушатели, че е настъпило събитие“. Редът на слушателите също се запазва, ако е важен. Вероятно обаче не трябва да е така. Ако listenerB не може да обработи събитие, докато listenerA вече не го е обработил, тогава listenerB вероятно се интересува повече от събитие, генерирано от listenerA, отколкото от обекта, който е слушал. Или това, или трябва да имате друг клас, чиято отговорност е да знае реда, в който дадено събитие трябва да бъде обработено.