2

クラスAのエンティティを持つアプリケーションがあります。AにはフィールドBがあり、すべてではありませんが一部のビューモデルで使用されます。フィールドBは、別のソースから別のロード操作でロードされます。

このフィールドBのロードを担当するレイヤーはどれですか？私は3つの選択肢を見ます：

  1. Aにロジックを実装して、アクセスされるたびにBをロードします。これは機能しますが、Aクラスにいくつかのロジックが必要です。エンティティクラスには最小限のロジックが必要であり、データソースからのデータのロードに関連するロジックは確かにないはずだと思います（ただし、間違っている可能性があります）。
  2. データアクセス層（DAL）がAのインスタンスをロードするたびにBをロードします。これは、データソース（リモートサーバー）からのデータのロードが遅く、Aのインスタンスの一部のみがフィールドを必要とするため最適ではありません。 B。
  3. 必要に応じて、DALを使用してビューモデルにBをロードさせます。これは私（MVVMの方法に比較的経験の浅い人）がこれを行うための最も「MVVM-y」の方法であるように思われます。

＃3は、「正しく機能する」要素に関しては、＃1に比べて「エレガント」ではないようです（＃1を使用すると、フィールドBにアクセスするとデータソースから自動的にロードされます）。しかし、＃3は、エンティティオブジェクトにさらにデータをロードする責任が与えられていないため、関心の分離をより適切に分離しているようです。

4

1 に答える 1

2

＃3に行きます。

クライアント アプリの場合はデータ転送オブジェクトである必要があるエンティティ モデルには、ロジックがまったく含まれていてはなりません。これにより、(おそらく) 単体テストを作成したり、dto を変更したりするときに、多くの時間を節約できます。

マスター アイテムを表す各ビュー モデルに依存関係を挿入し、データを取得できるようにします。これにより、アイテム ビュー モデルの IsBusy プロパティを使用して、ビジー インジケーターを使用してユーザーに簡単に通知することもできます。

ダウンロード タスクを処理する個別の Command クラスを実装することもできますが、処理中の操作でユーザーに通知する上位レベルのサービスが必要になりますが、これは私が想像できる最もクリーンなアプローチです。

したがって、3 から始めて、子をダウンロードするロジックがコマンド クラスにカプセル化するのに十分なほど大きくなる場合は、そのまま実行してください。しかし、どんな犠牲を払っても静的移植を避けるようにしてください。

悪い文法でごめんなさい。

于 2012-09-17T09:54:57.097 に答える