Допустимо ли использовать агрегатор событий для связи между классами моделей в приложении WPF MVVM?

Question

Я не уверен, что хороший / правильный способ связи между классами моделей в приложении WPF MVVM. Прямо сейчас мои классы моделей используют агрегатор событий (в частности, Caliburn.Micro) для связи с другими классами моделей.

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

Примечание : в настоящее время один и тот же агрегатор событий используется для связи между классом модель- и модель-классом <->. Мне показалось, что это нежелательно, и, если ответ на мой вопрос положительный, я мог бы легко создать отдельный агрегатор событий, предназначенный для связи между классом модели <-> модели.

Я понимаю полезность агрегатора событий, особенно для связи viewmodel <-> viewmodel и viewmodel <-> model. Но обсуждаемое приложение имеет довольно сложную модель, и я не уверен, что использование агрегатора событий является подходящим выбором для связи модели <-> модели.

Допустимо ли использовать агрегатор событий для связи между классами моделей в приложении WPF MVVM?

Если да, я должен использовать 2 агрегатора событий в моем приложении?

• Один для viewmodel <-> viewmodel & viewmodel <-> модель класса общения.
• Один для связи между моделями <-> модельного класса.

Если нет, какую альтернативу вы бы предложили?

Спасибо!

Редактировать: Прошло чуть более 2 месяцев с тех пор, как я спросил об этом. За это время я провел значительную реорганизацию и рефакторинг своего приложения. В этом процессе мне удалось исключить 99% использования агрегатора событий в моем приложении. В итоге я обнаружил, что большинство использований агрегатора событий ненужно (у меня было s *** ton). Мне удалось исключить сообщения агрегатора событий, лучше организовав свое приложение, и я также заменил некоторые сообщения наблюдаемыми (отличная альтернатива IMO). Так что, если кто-то увидит, что это в значительной степени зависит от агрегатора событий, сделайте шаг назад и подумайте, что вы делаете, потому что, вероятно, есть лучший способ сделать это!

Answer 1

Очевидно, что есть несколько подходов, которые вы можете использовать для общения между классами, но я думаю, что это довольно просто Да, прекрасно .

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

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

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