При реализации шаблона слабой ссылки и / или потоковой синхронизации для делегатов существуют ли руководящие указания или / или шаблоны, касающиеся того, где должна быть реализована логика?
Учтите, что класс WindowA хочет подписаться на событие в DataB , где DataB - это долгоживущий экземпляр, который изменяется во многих (не -UI темы).
Варианты реализации слабых синхронизированных событий:
Вариант 1: когда WindowA присоединяет делегат к пользовательскому событию в DataB , логика события cusom проверяет SynchronizationContext.Current для вызывающего потока и сохраняет его таким образом. что позже, когда событие возникает, делегат может быть вызван через SynchronizationContext. или:
Опция 2: WindowA реализует ProxyC , который действует как цель для DataB . Целевые методы в ProxyC реализуют синхронизацию и логику слабых ссылок и перенаправляют вызовы методов в WindowA . WindowA может собираться мусором, но ProxyC должен отсоединяться от всех событий, прежде чем его можно будет собирать. или:
Опция 3: WindowA использует утилиты преобразования делегатов (например, из SharpObservation ), чтобы делегаты были слабыми и синхронизировались перед присоединением их к событиям на DataB .
i.e.:
DataB.PropertyChanged + = new PropertyChangedEventHandler (WindowA.HandlePropertyChanged) .MakeWeak ()
Прежде всего ... есть ли смысл в Варианте 1? Хотя это удобное место для реализации со слабой логикой ссылок и синхронизации, кажется, что она нарушает шаблон единой ответственности, заставляя объект данных осознавать синхронизацию и ссылаться на семантику.
Вариант 2 кажется красивым и чистым. Мне он нравится во всех отношениях, за исключением того факта, что он требует дополнительной работы по созданию дополнительного класса для обработки слабых ссылок. Тем не менее, вы получите утечку памяти, если прокси-сервер не знает, как удалить делегатов, нацеленных на нее.
Вариант 3 позволяет самим делегатам нести ответственность за синхронизацию и слабые ссылки, но имеет недостаток, заключающийся в том, что служебные методы должны вызываться кодом, присоединяющим события. Насколько я знаю, большинство технологий привязки данных пользовательского интерфейса не позволяют вам контролировать привязку данных к событиям в DataB (отсюда и прелесть варианта 1).
БОЛЬШОЙ вопрос ... Есть ли здесь один универсальный шаблон? Существует ли единственная модель лучше всех остальных?