Шаблон проектирования наблюдателя и модель делегата события C # - PullRequest
4 голосов
/ 23 июня 2010

Кажется, что шаблон проектирования наблюдателя встроен в C # через его модель делегата события.Есть ли какая-то причина, по которой мне, возможно, придется реализовать это классическим способом?

привет123Developer

Ответы [ 6 ]

6 голосов
/ 23 июня 2010

Как правило, модель события, встроенная в язык, будет достаточной для модели наблюдателя. На самом деле нет никакой причины реализовывать его по-другому, поскольку вы просто воссоздаете события.

Как говорится, бывают редкие случаи, когда люди меняют "стандартный" шаблон событий. Например, я видел случаи, когда люди хотят вызывать события асинхронно. Обычно я не рекомендую это (лично я думаю, что это лучше обрабатывать на стороне подписчика), но это все еще может быть обработано с помощью стандартного события C #, но повышение события немного меняется (с использованием GetInvocationList и асинхронного вызова делегатов) .

3 голосов
/ 23 июня 2010

ты прав.шаблон наблюдателя реализован в системе событий 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

2 голосов
/ 23 июня 2010

Я думаю, что в целом нет реальной причины, по которой мы не должны использовать модель делегата C # для реализации шаблона Observer.Но в .Net 4 они добавили интерфейсы IObserver<T> и IObservable<T> для реализации системы push-уведомлений.Так что, я думаю, это один из случаев, когда вы захотите использовать интерфейсы, а не модель, основанную на событиях.

1 голос
/ 23 июня 2010

Я согласен, что обработчики событий .NET позаботятся о большинстве ваших потребностей в шаблоне наблюдателя.Однако есть пара интерфейсов, о которых вы захотите знать, особенно для Silverlight и WPF.Это INotifyPropertyChanged и INotifyCollectionChanged.Они предписывают конкретные шаблоны, которые Silverlight и WPF ожидают для привязки данных.Также есть класс ObservableCollection, который реализует INotifyCollectionChanged;это экономит много времени при создании интерфейсов Silverlight и WPF.

0 голосов
/ 23 июня 2010

Я бы посмотрел на этот пост:

Аналогичный вопрос по SO

Мне особенно нравится один комментарий от Джона Скита:

Абсолютно. Это похоже на вопрос: «Должен ли я реализовать шаблон итератора или использовать foreach и IEnumerable?»

Что было в ответ на этот хорошо сказанный ответ:

Хм, события могут использоваться для реализации шаблона Observer. На самом деле, использование событий можно рассматривать как еще одну реализацию паттерна-наблюдателя imho.

Но выбранный ответ довольно хорош и применим.

0 голосов
/ 23 июня 2010

Я согласен, что классический шаблон проектирования наблюдателя значительно упрощен в C #.Я думаю, что, возможно, существуют случаи, когда «безопаснее» использовать классическую реализацию.На ум приходят многопоточные и общедоступные API.Я думаю, что модульное тестирование иногда может быть проще, если вы делаете классический путь.Но, как вы упомянули, теперь с делегатами C # стало намного проще.Извините, у меня нет однозначного ответа, когда вам придется использовать классический шаблон.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...