Eventaggregator против услуг - PullRequest
Новая
       25

Eventaggregator против услуг

2 голосов
/ 30 декабря 2011

При разработке довольно крупных приложений, использующих Prism и MEF / Unity, я всегда достигаю точки, когда я должен выбирать между использованием событий, службы или, может быть, обоих. И я не могу решить, что наиболее пригодно для использования. Может быть, что-то не так с моей архитектурой (как в это решение не нужно было принимать в первую очередь ), но я не вижу, что.

Вот типичный пример: мое приложение имеет главное окно и множество подчиненных окон, которые создаются по требованию модулями или действиями пользователя. Приложение решает, как выглядит и ведет себя хром ведомого окна, запоминает расположение окон и т. Д., А сам контент создается где-то в модулях. Есть также много действий пользователя, приводящих к скрытию / показу / переносу перед окнами. Чтобы добиться всего этого, в настоящее время у меня есть служба WindowManager, которая прослушивает события CreateWindow / SetWindowState / ...

Это имеет преимущества:

  • классы, использующие это, знают только о IEventAggregator (который они в любом случае уже используют большую часть времени для других событий) и событиях, потребляемых WindowManager, но не сам WindowManager
  • классы, такие как ViewModels, не имеют дело с окнами напрямую. Вместо этого они ссылаются на них по их названию или идентификатору и небольшим классам событий, которые инкапсулируют только то, что нужно.
  • нет необходимости в отдельном интерфейсе IWindowManager только для проверки его в тесте

И вывод средств:

  • WindowManager можно использовать совершенно автономно, но теперь ему нужно подписаться на события. Или, возможно, лучше, другой класс должен позаботиться об этом.
  • расширение его для показа модального диалога несколько сложно: если виртуальная машина запускает событие для показа диалога, крайне важно, чтобы вызов Publish возвращался только после закрытия диалога
  • WindowManager доступен как сервис и находится в CompositionContainer, почему бы не использовать его как таковой?

Использование услуги напрямую просто меняет преимущества и выплаты, и, похоже, нет явного победителя.

Вопрос: что бы вы использовали в качестве правил руководства для выбора того или другого, или вы бы предпочли всегда выбирать только одно или оба? Есть ли что-то особенно неправильное в дизайне моего приложения, что я должен принять это решение?

1 Ответ

3 голосов
/ 30 декабря 2011

События и сервисы используются для разных вещей. Вам не нужно выбирать между ними, вы можете использовать их для разных целей. Обычно вы используете событие, чтобы уведомить слушателей о том, что что-то произошло. Пример: пользователи изменяют размер шрифта в настройках приложения. Вы бы отправили событие всем слушателям (например, viewmodels), чтобы представления обновлялись. Обычно событие - это такая вещь, на которую вы не получаете ответ (хотя вы можете прикрепить, например, функцию / действие обратного вызова, которую вызовет прослушиватель событий).

Что если вашей viewmodel нужно открыть новое окно? Обычно viewmodel не должно волновать, как открывается это новое окно, является ли оно модальным или нет. В этом случае было бы легко воспользоваться услугой: 

windowManager.ShowDetailsView();

WindowManager (который вы используете через интерфейс IWindowManager) отвечает за отображение подробного представления. Может быть, это модальный вид или может быть какая-то анимация слайдов. Дело в том, что модели представления, использующей IWindowManager, все равно.

В некоторых случаях вам может потребоваться получить уведомление, если пользователь нажимает кнопку «ОК» или «Отмена». Вы все еще можете использовать IWindowManager, имея такой метод: 

public void ShowEditView(Action userSavedChanged, Action userCancelled);

Тогда просто вызовите его из модели представления 

windowManager.ShowEditView(this.SaveChanges, this.CancelChanges);

// in your viewmodel you have the SaveChanges and CancelChanges methods
private void SaveChanges()
{
   // save the changes.
}

Надеюсь, все это имеет смысл. Ведь это пятница:)

...