MVVMとサービスパターン

MVVMパターンを使用してWPFアプリケーションを構築しています。現在、私のビューモデルは、サービスレイヤーを呼び出してモデルを取得し（ビューモデルとは無関係です）、モデルをビューモデルに変換します。コンストラクター注入を使用して、必要なサービスをビューモデルに渡します。

簡単にテストでき、依存関係の少ないビューモデルでうまく機能しますが、複雑なモデルのviewModelを作成しようとするとすぐに、多くのサービスが挿入されたコンストラクターがあります（各依存関係と使用可能なすべての値のリストを取得するためのもの）たとえば、itemsSourceにバインドします）。そのような複数のサービスをどのように処理し、簡単にユニットテストできるビューモデルがまだあるのか疑問に思っています。

私はいくつかの解決策を考えています：

1. 使用可能なすべてのサービスをインターフェイスとして含むサービスシングルトン（IServices）を作成します。例：Services.Current.XXXService.Retrieve（）、Services.Current.YYYService.Retrieve（）。そうすれば、大量のサービスパラメータを含む巨大なコンストラクタはありません。

2. viewModelによって使用されるサービスのファサードを作成し、このオブジェクトを私のviewmodelのctorに渡します。しかし、その後、複雑なビューモデルごとにファサードを作成する必要があります。

この種のアーキテクチャを実装する「正しい」方法は何だと思いますか？

実際、これらのソリューションはどちらも悪いです。

使用可能なすべてのサービスをインターフェイスとして含むサービスシングルトン（IServices）を作成します。例：Services.Current.XXXService.Retrieve（）、Services.Current.YYYService.Retrieve（）。そうすれば、大量のサービスパラメータを含む巨大なコンストラクタはありません。

これは、本質的にはService Locator Patternであり、アンチパターンです。これを行うと、プライベート実装を確認しないと、ビューモデルが実際に依存するものを理解できなくなり、テストやリファクタリングが非常に困難になります。

viewModelによって使用されるサービスのファサードを作成し、このオブジェクトを私のviewmodelのctorに渡します。しかし、その後、複雑なビューモデルごとにファサードを作成する必要があります。

これはそれほどアンチパターンではありませんが、コードの匂いです。本質的にはパラメーターオブジェクトを作成しますが、POリファクタリングパターンのポイントは、頻繁に多くの異なる場所で使用されるパラメーターセットを処理することですが、このパラメーターは一度しか使用されません。あなたが言及したように、それは実際の利益のために多くのコードの膨張を作成し、多くのIoCコンテナでうまく動作しません。

実際、上記の両方の戦略は全体的な問題を見落としています。つまり、ビューモデルとサービスの間の結合が高すぎるということです。単純に隠れサービスロケータでこれらの依存関係を、パラメータオブジェクトが、実際にはありません変更ビューモデルが依存するどのように多くの他のオブジェクト。

これらのビューモデルの1つを単体テストする方法を考えてください。セットアップコードはどのくらいの大きさになりますか？動作させるために初期化する必要があるものはいくつですか？

MVVMを開始する多くの人は、画面全体のビューモデルを作成しようとしますが、これは根本的に間違ったアプローチです。MVVMはすべて構成です。多くの機能を備えた画面は、それぞれ1つまたは少数の内部モデル/サービスに依存する複数の異なるビューモデルで構成する必要があります。相互に通信する必要がある場合は、pub / sub（メッセージブローカー、イベントバスなど）を介して通信します。

実際に行う必要があるのは、ビューモデルをリファクタリングして、依存関係が少なくなるようにすることです。次に、集約「画面」が必要な場合は、別のビューモデルを作成して、より小さなビューモデルを集約します。この集計ビューモデルは、それ自体でそれほど多くのことを行う必要はありません。したがって、このモデルは、理解とテストもかなり簡単です。

これを適切に行った場合、コードを見るだけで明白になるはずです。なぜなら、短くて簡潔で、具体的で、テスト可能なビューモデルがあるからです。

私はこれについて本を書くことができます...実際に私は;）

まず、物事を行うための普遍的な「正しい」方法はありません。他の要因を考慮する必要があります。

サービスの粒度が細かすぎる可能性があります。特定のViewmodelまたは関連するViewModelのクラスターでさえ使用するインターフェースを提供するFacadeでサービスをラップすることは、より良いソリューションかもしれません。

さらにシンプルなのは、すべてのビューモデルが使用する単一のファサードにサービスをラップすることです。もちろん、これは平均的なシナリオでは多くの不要な機能を備えた非常に大きなインターフェイスになる可能性があります。しかし、システム内のすべてのメッセージを処理するメッセージルーターと同じです。

実際、多くのアーキテクチャが最終的に進化するのを見てきましたが、Event Aggregatorパターンのようなものを中心に構築されたメッセージバスです。テストクラスはリスナーをEAに登録し、それに応じて適切なイベントを発生させるだけなので、テストは簡単です。しかし、それは成長するのに時間がかかる高度なシナリオです。私は統一されたファサードから始めて、そこから行くと言います。

両方を組み合わせてみませんか？

ファサードを作成し、ビューモデルが使用するすべてのサービスを配置します。その後、悪いSの単語なしで、すべてのビューモデルに単一のファサードを作成できます。

または、コンストラクター注入の代わりにプロパティ注入を使用できます。しかし、その後、それらが適切に注入されていることを確認する必要があります。