0

MVVM light toolkit を使用する WPF アプリケーションがあるとします。

このツールキットの良い例は Locator です。サービスを登録してインターフェイス駆動型にすることを可能にする SimpleIoC が含まれていることは素晴らしいことです。

Locator コンストラクターが実際に大きくなることがあります。残念ながら、インターフェースを登録する以外に、次のようなロジックが含まれています。

if(SimpleIoc.Default.GetInstance<MainViewModel>().LoadProject())
{
var project = SimpleIoc.Default.GetInstance<MainViewModel>().LoadedProject
SimpleIoc.Default.Register<ConfigService>(new Service(project))
}

これは単なる例でした-ロケーターコンストラクター中にさらにロジックが必要な場合。サービス アーキテクチャが独立していないために間違って作成された可能性があります。または、そのような場合は、ロケータの使用を辞任する必要がありますが、そうすると DI が失われます。

もう 1 つのことは、いくつかの ViewModel に Locator.GetInstance への参照があることです。これは、テスト容易性を有効にするためにコンストラクターを介して注入する必要があるため、別の良い方法ではありません。

もう 1 つの側面は、AvalonDock で正しく使用することです。

AvalonDock は、アンカー可能でドッキング可能なペインを備えた Visual Studio などのアプリに似たアプリを準備できる、優れたアンカー可能なコントロールです。

このペインは実際には、プロパティを介して AvalonDock にバインドされた別の ViewModel です。

MainViewModel にはプロパティ Tools = new Tools[] { ViewModel1, ViewModel2} があります

しかし、各 ViewModel は Locator に登録されていました。

したがって、MainViewModelでそれらを（DRYに違反して）使用しています

プロパティのゲッター: Locator.GetInstance()

私の意見では、これは別の悪い例です-安全ではありません. Avalon ツールの ViewModel1 が必要とするサービスがまだ登録されていないが、MainViewModel のインスタンス化中に getter を介して呼び出された場合はどうなるでしょうか。

ミスマッチになり始めました。何か良い練習はありますか？

Workspaces (MainViewModel) などの多くの例を見つけましたが、非常に便利な Locator を同時に使用している人は誰もいませんでした。

依存性注入とインターフェイス駆動のおかげで、mme がプロジェクトをテスト可能にするのは良いことだと思うので、Locator を維持したいと思います。

アイデアの提案はありますか？ありがたく思います。

4

1 に答える 1

0

私はこれを避けるでしょう。ご指摘のとおり、ここでは単に型を登録するだけでなく、さらに多くのことが行われています。

代わりに、コンストラクターで ConfigService インスタンスを Viewmodel に渡します。最初に登録する限り、構成サービスとビュー モデルを IOC できます。

SimpleIOC.Register<IViewModel>(()=>{return new ViewModel(SimpleIOC.GetInstance<IConfigService>())});

... それはすべてメモリからのものなので、正確ではないかもしれませんが、SimpleIOC のカスタム コンストラクターのアイデアを示しています。

次に、ビュー モデル コンストラクターで、それ自体をパラメーターとして渡すサービス .Register メソッドを呼び出すことができます。

これにより、ビューモデルに「知識」が保持され、ロケーターは本来の処理に集中できます。

于 2014-10-19T07:51:15.963 に答える