2

WPF と MVVM デザイン パターンを使用してアプリケーションを作成しています (MVVM パターンも初めてです)。このアプリケーションは、ユーザーが視聴した映画を管理および追跡します。また、映画のメタデータをダウンロードするには、外部の Web サイトに接続する必要があります。.NET TMDb と Rotten Tomatoes ライブラリを使用してこれを行っています。

現在、MovieModels フォルダーにクラスがあり、そのクラスには、フィルムのすべてのプロパティと、TMDb/RT ライブラリのセットアップ、一致する結果の検索、およびすべてのメタデータのダウンロードに必要なメソッドとロジックが含まれています。しかし、これにより、私のMovieクラスは、私が思っているよりもかなり雑然として重くなっています。

MovieViewModelサード パーティの API にアクセスするためのメソッドとロジックを1 つまたは別のクラスに完全に移動する方が理にかなっていますか? Model クラスはどの程度単純であるべきか?

4

2 に答える 2

5

Modelクラスはどのくらいシンプルにする必要がありますか？

通常、POCO -simple。モデルレイヤーは、ドメインオブジェクトの定義とビジネスロジックのように考えるのが安全です。ドメインオブジェクトは通常、単なるデータホルダー（前述のPOCOクラスなど）ですが、ビジネスロジックは、アプリケーションの要求された機能（データの取得、永続性、他のAPIとの通信など）を実行するために必要なものです。

ViewModelは、すべてを結合して表示にフィードする接着剤です。

サードパーティのAPIにアクセスするためのメソッドとロジックをMovieViewModelまたは別のクラスに移動する方が理にかなっていますか？

はい。関心の分離、テスト容易性、または一般的にビューモデルレイヤーが乱雑にならないようにするために（モデルクラスは、正しく実装されている場合、ビューモデルで簡単に再利用できます[POCO-正しくは]）。

また、モデルをさらに分離することを検討してください。

Model.Entities-POCOドメインオブジェクト
Model.Contract-ビジネスロジックのインターフェイス
Model。*-上記の具体的な実装

これには複数の利点があります。

  • エンティティ（ドメインオブジェクト）がデータアクセス層（一般的な悪用される傾向があります）と混同されていません。その結果、データレイヤーを置き換えたり、新しいデータベースサポートを追加したりするのは非常に簡単です。
  • エンティティアセンブリは、その単純さ（POCOのみ）により、他のプロジェクトで簡単に再利用できます。
  • ビューモデルは、エンティティとコントラクトアセンブリについてのみ知る必要があります。これらはクリーンな状態を保ち、実装の置き換え/再利用が簡単です。
  • プロジェクトは、ゆるく結合され、モジュール化され、柔軟性が保たれます。

全体として、モデルレイヤーを設計/実装する際の小さなミス（またはカジュアルな怠惰）は、プロジェクトの後の段階でひどく雪だるま式になります。DAL全体をVMにプルし、サードパーティのAPIアセンブリをVMにリンクすると（「モデルコードがスリップしたため」）、単体テストを記述できないのは、すべて不十分なレイヤー設計の結果です。その結果、再利用可能なビューモデルの代わりに、誰もが触れることを恐れているメンテナンス不可能なモンスターになってしまいます。

于 2013-01-28T19:34:12.767 に答える
0

つまり、データをダウンロードするためのコードを別のクラスに完全に移動します。モデルは、データの単純な表現である必要があります。アプリケーションコードでAPIヘルパーを呼び出してデータをダウンロードし、単純なモデルまたはモデルのリスト（またはモデルオブジェクトの階層）を取得します。次に、それらのモデルをビューモデルでラップし、ビューモデルをビューのDataContextにフィードします。

于 2013-01-28T19:40:56.083 に答える