Как часто вы используете пользовательские события?

Question

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

Итак, с точки зрения дизайна, когда лучше всего использовать события? Существуют ли определенные сценарии, для которых они очень удобны, но не более того? Или возможно создать приложение, которое в значительной степени зависит от них, и программист может использовать их столько, сколько они захотят?

В основном мне просто любопытно, куда они попадают в «правильную» конструкцию, поскольку я легко могу представить себе, что мое приложение или два опираются на них гораздо сильнее, чем на простое срабатывание логики класса контроллера, когда кнопка нажата.

Answer 1

Вы не видите столько пользовательских событий в коде asp.net, в основном потому, что вещи, которые могут вызвать «событие», обычно являются тем, что пользователь делал на клиенте с помощью одного из встроенных элементов управления, таких как кнопка или что-нет. Сам сервер на самом деле не «взаимодействует» с кодом, поскольку он выполняется управляемым событиями способом.

Тот, который вы получаете goind постбэк через один из обычных элементов управления. Выполнение на сервере имеет тенденцию быть очень процедурным по своей природе ... это просто шаблон, который имеет наибольшее значение в среде запросов / ответов без сохранения состояния, такой как сеть.

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

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

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

Answer 2

В основном я использую пользовательские события при создании пользовательских элементов управления.

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

В формах Windows почти все, что я делаю, где-то абстрагируется в элемент управления, поэтому я использую их совсем немного.

Answer 3

Я сделал много пользовательских событий в ActionScript 3.0. Я упоминаю об этом, потому что его система делегатов очень похожа на .NET.

Я создавал SWF-плеер, который мог ставить в очередь несколько клипов одновременно. Мой пользовательский элемент управления Timeline будет запускать события ClipEnd, которые мое основное приложение будет прослушивать и улучшать список воспроизведения. Мой список воспроизведения будет запускать события NewClip, если пользователь перейдет к новому клипу или приложение автоматически сделает это. Мое приложение будет прослушивать их и сообщать временной шкале, чтобы начать воспроизведение следующего клипа. Таким образом, моя Временная шкала и Плейлист были симбиотически связаны через пользовательские события.