Шаблон разработки наблюдателя и модель делегата события C#
Кажется, что шаблон разработки наблюдателя находится в созданном в C# через его модель делегата события. Есть ли какая-либо причина, где мне, вероятно, придется реализовать ее классическим способом?
с уважением
123Developer
6 ответов
Как правило, встроенной в язык модели событий будет достаточно для шаблона наблюдателя. На самом деле нет причин реализовывать его по-другому, так как вы просто воссоздаете события.
При этом бывают редкие случаи, когда люди меняют «стандартную» модель событий. Например, я видел случаи, когда люди хотят поднимать события асинхронно. Обычно я не рекомендую это (лично я думаю, что это лучше обрабатывать на стороне подписчика), но это все равно может быть обработано через стандартное событие C#, но повышение события немного меняется (используя GetInvocationList и асинхронный вызов делегатов).
вы правы. шаблон наблюдателя реализован в системе событий C # с использованием делегатов.
Причина №1, по которой вам может понадобиться нечто более близкое к классическому наблюдателю, - это даже агрегирование для облегчения событий предметной области и / или архитектур составных приложений.
Джереми Миллер написал отличный пост об агрегаторе событий: http://codebetter.com/blogs/jeremy.miller/archive/2009/07/21/braindump-on-the-event-aggregator-pattern. aspx
, и я использовал его сообщение для создания своего агрегатора событий, который я поместил в архитектуру на основе обмена сообщениями для моих winforms / портативных приложений: http://www.lostechies.com/blogs/derickbailey/archive/2009 /12/22/understanding-the-application-controller-through-object-messaging-patterns.aspx
Я думаю, что в целом нет реальной причины, по которой мы не должны использовать модель делегата C # для реализации шаблона Observer. Но в .Net 4 они добавили интерфейсы IObserver и IObservable для реализации системы push-уведомлений. Итак, я предполагаю, что это один из случаев, когда вы захотите использовать интерфейсы, а не модель, основанную на событиях.
Я согласен с тем, что обработчики событий .NET удовлетворяют большинство ваших потребностей в шаблоне наблюдателя. Однако есть пара интерфейсов, о которых вы должны знать, особенно для Silverlight и WPF. Это INotifyPropertyChanged и INotifyCollectionChanged. Они предписывают определенные шаблоны, которые Silverlight и WPF ожидают от привязки к базе данных. Также существует класс ObservableCollection, который реализует INotifyCollectionChanged; это избавляет от многих хлопот при создании интерфейсов Silverlight и WPF.
Я согласен с тем, что классический шаблон проектирования наблюдателя значительно упрощен в C #. Я думаю, что есть случаи, когда «безопаснее» использовать классическую реализацию. На ум приходят многопоточность и общедоступные API. Я думаю, что иногда модульное тестирование может быть проще, если вы будете делать это классическим способом. Но, как вы упомянули, теперь есть гораздо более простой ярлык с делегатами C #. Извините, у меня нет однозначного ответа, когда вам следует использовать классический шаблон.
Я бы взглянул на этот пост:
Мне особенно нравится один комментарий от Джона Скита:
Абсолютно. Это немного похоже на вопрос: «Должен ли я реализовать шаблон итератора или использовать foreach и IEnumerable?»
Что было ответом на этот хорошо сказанный ответ:
Хм, события можно использовать для реализации шаблона Observer. Фактически, использование событий можно рассматривать как еще одну реализацию паттерна наблюдателя imho.
Но выбранный ответ неплох и применим.