10

Messengerクラスを使用する適切な方法は何ですか？ViewModels / Views通信に使用できることは知っていますが、技術/ビジネスサービスレイヤーに使用するのは良いアプローチですか？

たとえば、ロギング/ナビゲーションサービスは、コンストラクター内の一部のメッセージを登録し、これらのメッセージがアプリでいつ発生するかを認識します。送信者（ViewModel ou Service）は、サービスインターフェイスを参照せず、メッセージを送信するためのメッセンジャーのみを参照します。サンプルサービスは次のとおりです。

using System;
using System.Windows;
using System.Windows.Navigation;
using Microsoft.Phone.Controls;
using App.Service.Interfaces;
using GalaSoft.MvvmLight.Messaging;

namespace App.Service
{
    public class NavigationService : INavigationService
    {
        private PhoneApplicationFrame _mainFrame;

        public event NavigatingCancelEventHandler Navigating;

        public NavigationService()
        {
            Messenger.Default.Register<NotificationMessage<Uri>>(this, m => { this.NavigateTo(m.Content); });
        }

        public void NavigateTo(Uri pageUri)
        {
            if (EnsureMainFrame())
            {
                _mainFrame.Navigate(pageUri);
            }
        }

        public void GoBack()
        {
            if (EnsureMainFrame()
                && _mainFrame.CanGoBack)
            {
                _mainFrame.GoBack();
            }
        }

        private bool EnsureMainFrame()
        {
            if (_mainFrame != null)
            {
                return true;
            }

            _mainFrame = Application.Current.RootVisual as PhoneApplicationFrame;

            if (_mainFrame != null)
            {
                // Could be null if the app runs inside a design tool
                _mainFrame.Navigating += (s, e) =>
                {
                    if (Navigating != null)
                    {
                        Navigating(s, e);
                    }
                };

                return true;
            }

            return false;
        }
    }
}
4

1 に答える 1

25

私にとって、メッセンジャーの主な用途は、viewModel 間の通信を可能にすることです。ビジネスロジックを検索機能に提供するために使用されるビューモデルと、検索を処理して出力を表示するページ/ウィンドウ上の3つのビューモデルがあるとしましょう。メッセンジャーは、疎結合でこれを行う理想的な方法です。仕方。

検索データを取得するビューモデルは、メッセージを消費するために現在登録されているものによって消費される「検索」メッセージを送信するだけです。

ここでの利点は次のとおりです。

  1. 各ビューモデルがお互いを知る必要がなく、ビューモデル間の簡単なコミュニケーション
  2. コンシューマーに影響を与えずにプロデューサーを交換できます。
  3. 少しの労力でメッセージ コンシューマーを追加できます。
  4. ビューモデルをシンプルに保ちます

編集： それで、サービスはどうですか？

ViewModel は、データを UI に表示する方法に関するものです。それらはあなたのデータを取得し、ビューに表示できるものに形作ります。ViewModel はサービスからデータを取得します。

サービスは、ViewModel にデータやビジネス ロジックを提供します。サービス ジョブは、ビジネス モデルの要求に対応することです。サービスがそのジョブを実行するために他のサービスと通信/使用する必要がある場合、依存性注入を使用してこれらをサービスに注入する必要があります。サービスは通常、メッセンジャーを使用して相互に通信しません。メッセンジャーは、ビューモデル レベルでの水平方向のコミュニケーションに関するものです。

私が行ったことの 1 つは、メッセンジャーをmediatorとして使用することです。この場合、ビューモデルに直接サービスを注入する代わりに、メッセンジャーが代わりにビューモデルに注入されます。ビューモデルはイベントをサブスクライブし、イベントからモデルを含むイベントを受け取ります。これは、安定した更新の流れを受信して​​いる場合、または単一のストリームにマージしたい複数のサービスから更新を受信して​​いる場合に最適です.

リクエスト/レスポンスタイプのリクエストを行っているときにサービスを注入する代わりにメッセンジャーを使用しても意味がありません。これを行うには、サービスを直接注入するだけで記述しなければならないコードをさらに記述する必要があるためです。コードが読みにくくなります。

上記のコードを見てください。そこに各メソッド (Navigate、CanNavigate、GoBack、GoForward など) のイベントを記述する必要があると想像してください。あなたはたくさんのメッセージで終わるでしょう。あなたのコードも従うのが難しくなります。

于 2012-09-05T13:15:18.177 に答える