2

PRISMとEnterprise Libraryを使用して多くの CRUD 操作を行う LOB デスクトップ アプリケーションで作業しているときに、煩わしいパターンが繰り返し発生することに気付きました。すべてのドメイン モデル エンティティ (例: Contact) について、ビュー モデル (例: ContactVM) でそれをラップしているのを見つけてからContactsVM、後者のクラスが入力に使用されるリポジトリ インターフェイスを受け入れる新しい (「s」に注意してください) を導入します。と、リポジトリから読み取っObservableCollection<ContactVM>たすべてのContactエンティティを にラップしContactVM、ViewModel が必要とする他のエンタープライズ ライブラリ サービスと共にコンストラクターを介してエンティティを渡します。

問題は、すべてのビュー モデル コンストラクターがこのパターンを次のように取り始めたことです。

ViewModel(EntityToWrap e, DependencyFromEntLib, OtherDependencies ...)

ほとんどのツールとライブラリはデフォルトのパラメーターなしのコンストラクターを必要とするため (たとえば、一部の商用データ グリッドではフィルター処理のサポートを提供する必要があります)、さらにパラメーターなしのコンストラクターも必要であるため、設計データを使用してエンティティを視覚化できないため、これが問題になります。そして最後に質問: ビュー モデルを構築する正しい方法は何ですか? また、コンストラクターまたはServiceLocatorを介して Entlib サービスを提供する必要がありますか?

4

1 に答える 1

11

以下は、問題にアプローチするさまざまな方法の 1 つです。

私は、はるかに軽量なビュー モデルを好みます。次に、ビュー モデルを 1 つ以上のソース (リポジトリなど) から構成するクラスを追加します。これにより依存関係のカスケードの問題が解消されるわけではありませんが、ビュー モデル コンストラクターが解放されます。

また、コントローラーからロジックを除外し、ビュー モデルを再利用できるようにします (もちろん、適切な場合)。

  • 軽量ビュー モデル

  • 軽量コントローラーは、ビューモデルをアセンブルするコンポーザーを見つける方法を知っています (DI フレームワークを使用して、すべての依存関係でコンポーザーをセットアップできます)。コントローラは、セットアップ プロセスで小さな役割を果たしますが、シンプルに保つ必要があります。

  • コントローラーは、ビュー モデルをどのように組み立てるべきかを認識しており、それをコンポーザー クラスと共有します。たとえば、アクションは、子が設定されていない同じビュー モデルを引き続き利用できる概要ビューを要求する場合があります。

  • Composer は、ビュー モデルを完成させるために必要な情報を組み立てます。Composer は、他の Composer を使用して、直接責任を負わない情報を収集する場合があります。ここでも、DI フレームワークを使用して、これらのコンポーザーに必要な依存関係を与えることができます。

  • コントローラーは、完成したビュー モデルを使用して通常どおりビューをレンダリングします。

私の意見では、これはより良いレベルの抽象化も提供します。ビュー モデルが特定のドメイン モデルのように見えることが多いからといって、常にそうであるとは限りません。

最終結果:

  • 多くのクラス (マイナス面、当然) が、コードの繰り返しは最小限 (つまり DRY)

  • テスト可能なシン ビュー モデル (必要に応じて...テストするものが何も含まれていない場合があります)

  • 薄型でテスト可能なコントローラー。

  • さまざまなシナリオで再利用できるテスト可能なコンポーザー オブジェクトは、(おそらく) さまざまな目的でビュー モデルを組み立てる方法を知っているためです。

  • さまざまなシナリオをサポートするために、ビュー モデル、コントローラー、およびコンポーザーを組み合わせて使用​​できる柔軟性。

于 2013-01-03T02:14:48.580 に答える