0

私が取り組んでいるプロジェクトでは、コードベースのどこからでもメッセージをフロントエンドに送り返し、ログを記録したり、ユーザーに表示したりするための一般的なメカニズムを開発しようとしています.

エラー/例外が原因で、進行状況などを報告するためにメッセージを送信できます。最初は、log4net のようなものを使用してメッセージ データを報告し、アプリケーション レベルでカスタム アペンダーを使用してこれらのメッセージを消費し、表示/ログとして記録することを考えました。適切な。ただし、いくつかの問題があるため、これが最善のアプローチであるかどうかはわかりません

1) プロジェクトは多数の個別のアセンブリに分割されており、複数の dll にわたる log4net の構成に問題があることがわかりました。

2) このメッセージング スキームは単なるロギングではありません。そのため、ロギング フレームワークを使用すると制限が厳しすぎる可能性があります。

現時点では、C# カスタム メッセージ イベントを使用してアセンブリからデータを送信し、アプリケーション レベルでハンドラーを登録してそれらをキャプチャしています。

しかし、MVVMLight の Messenger クラスはまさに私が探していたものであり、アセンブリ間で汎用データ パケット (クラス) を送信する方法であることに気付きました。しかし、モデル コードからメッセージを送信している可能性があるため、MVVMLight への不必要な依存関係がモデル コードに追加されているのではないかと考えています。

私の印象では、Model コードはできるだけ依存関係を持たないようにする必要があるため、修正せずに任意のアプリケーション フレームワークにドロップできます。

皆さんはどう思いますか？

4

1 に答える 1

0

それがあなたがやろうとしていることなら、Messenger クラスを使うべきです。

モデル コードが別のアプリケーションで使用される可能性は (実際には) どれくらいありますか? それが一般的なもの (ユーザー設定、セキュリティなど) である場合は、別の場所で使用したいかもしれませんが、特注のビジネス データを提供している場合はYAGNI .

グッドプラクティスの観点から、次のようなことをお勧めします。

public interface IMessenger<T>
{
    public void Send(T message);
}

public class MessengerProxy:IMessenger<ErrorDto>
{
    public void Send(ErrorDto error)
    {
        Messenger.Default.Send(error);
    }
}

public class AnotherModel
{
    public AnotherModel(IMessenger<ErrorDto> errorRegister)
    {
        _errorRegister=errorRegister;
    }

    private RegisterError(Exception ex)
    {
      var dto=new ErrorDto(ex,"My Title");
      _errorRegister.Send(dto);
    }
}

MessengerProxy を MVVM Light に登録し、Model クラスのコンストラクターに挿入します。上記のモデル クラスでは、インターフェイスをコンストラクターに挿入します。これにより、Messenger にアクセスできるようになりますが、後で必要に応じて基になる実装を変更することができます。

于 2012-11-26T09:25:13.033 に答える