どのMVVMフレームワークが良いですか？

Question

導入されたMVVMフレームワークをいくつか知っています これ スレッド

そのためのリンクを説明または教えてください。 MVVMフレームワークに関するMVVMに関する情報ではありません。ありがとう:)知りたい：MVVMフレームワークとは何ですか？

Answer 1

あなたの質問は本当に正確ではないと思います。私が理解する限り、あなたは各フレームワークの機能を求めますか？！

詳細情報を見つけることができます ここ と ここ. 。ただし、これらのリンクの少なくとも1つは、あなたが言及したスレッドですでに与えられています...

編集：
基本的に、MVVMフレームワークは、MVVM（Model-View-ViewModel）パターンを使用してアプリケーションで一般的に使用されるクラスのコレクションです。これには、ソフトウェアの独立した部分間で通信するメッセージングシステムが含まれます。

このようなフレームワークを完全に理解するには、最初にMVVMパターンを理解する必要があります。その時だけ（または、最初のMVVMプロジェクトを行った後にのみ）、このパターンの問題や課題を理解することができるからです。

Answer 2

MVVMフレームワークを使用するには、以下の手順に従うだけです。

1. 同じ名前のモデルとビューモデルがあります。

ビューモデルは、モデルの周りのラッパーであるとは思われません。ビューモデルの仕事は、データの読み込みや保存などの外部サービスのリクエストを仲介することです。データ自体、および検証とほとんどのビジネスロジックは、モデルにある必要があります。

私はこれを十分に強調することはできません。代表団によってモデルをラップするビューモデルを作成するたびに、APIに大きな穴を紹介します。特に、モデルを直接参照するものはすべて、ビューモデル、したがってUIが通知されないようにプロパティを変更できます。同様に、モデル内の計算されたフィールドの変更は、ビューモデルに戻ることはありません。

1. 同じ名前のビューとビューモデルがあります。

理想的には、ビューモデルは、使用されている画面に不可知論されます。これは、複数のウィンドウがビューモデルと同じインスタンスを共有しているWPFアプリケーションで特に当てはまります。

小規模なアプリケーションの場合、アプリケーション全体に単一のビューモデルのみが必要になる場合があります。大規模なアプリケーションの場合、メイン機能には1つ、構成管理などのセカンダリアスペクトごとに1つ必要になる場合があります。

1. 背後にコードがありません。

絶対的な用語では、背後にあるコードは良いことでも悪いことでもありません。これは、単一のビューまたは制御に固有のロジックを配置する単なる場所です。したがって、コードビハインドのないビューを見ると、すぐに次の間違いを確認してください。

• ビューモデルは名前で特定のコントロールをタッチしますか？
• ビューモデルには、コマンドパラメーターを介してコントロールへのアクセスが与えられていますか？
• EventToCommandまたは別の漏れやすい動作は、単純なイベントハンドラーの代わりに使用されていますか？

MVVMライトからのEventToCommandは、画面から削除された後にコントロールが収集されるのを防ぐため、特に悪いです。

1. ビューモデルは、プロパティ変更通知を聞いています

モデルのライフスパンが長い場合、イベントを聴くビューモデルがある場合、おそらくメモリリークがあります。アンロードされたイベントがあるビューとは異なり、ビューモデルにはライフサイクル管理に適したストーリーがありません。したがって、彼らがそれらを終わらせる可能性のあるモデルにイベントを添付すると、ビューモデルがリークされます。